[Opensim-dev] Dynamic attributes

Thu Feb 7 02:11:03 UTC 2013

A word of caution:

Many people have scripts that would store copious amounts of data.
Some limits need to be placed on the overall storage given to a
script so it becomes unattractive to store lots of data in the
simulator. Scripts needing lots of storage should use a web server,
not sim resources.

Melanie

On 07/02/2013 02:59, Mic Bowman wrote:
> for discussion purposes...
> 
> added the jsonstore connection to the dynamic attributes. here's an example
> of an LSL script that sets the attributes (create a notecard called
> JsonData with some json structure inside it)... you can interrogate the
> store through channel 30... eg "/30 jstoretest.test1.field"
> 
> btw... i really think that hooking up the object store with a variant of
> llrezobject() would be very good. it would make passing more complex
> initialization parameters a LOT easier (better than the one integer you get
> right now). i'm doing this with a modified version that uses a global
> jsonstore...
> 
> --mic
> 
> 
> integer iChannel = 30;
> string sInitCard = "JsonData";
> key kStoreID;
> 
> InitializeObjectStore()
> {
>     llOwnerSay("initializing the object store");
>     JsonSetValueJson(kStoreID,"jstoretest","{'test1': {'field' : 22}}");
>     JsonReadNotecard(kStoreID,"jstoretest", sInitCard);
> }
> 
> default
> {
>     state_entry()
>     {
>         kStoreID = JsonAttachObjectStore();
>         if (JsonTestPathJson(kStoreID,"jstoretest") == 0)
>             InitializeObjectStore();
> 
>         llOwnerSay("object store is " + JsonGetValueJson(kStoreID,"."));
> 
>         llListen(iChannel,"",llGetOwner(),"");
>     }
> 
>     listen(integer ch, string name, key id, string msg)
>     {
>         if (ch == iChannel)
>         {
>             list tokens = llParseString2List(msg,[" "],[]);
>             string path = JsonList2Path(tokens);
>             string value = JsonGetValueJson(kStoreID,path);
>             llOwnerSay(path + " == " + value);
>         }
>     }
> }
> 
> 
> 
> On Wed, Feb 6, 2013 at 3:00 PM, Mic Bowman <cmickeyb at gmail.com> wrote:
> 
>> one more thing... is there a strong reason for XML serialization as
>> opposed to json? (I assume the primary reason is for consistency with other
>> properties.) the OSDMap data structure corresponds fairly closely to JSON.
>> serializing works fine for either format though it is easy to provide an
>> xml document that will not deserialize into an OSDMap.
>>
>> --mic
>>
>>
>> On Wed, Feb 6, 2013 at 1:58 PM, Mic Bowman <cmickeyb at gmail.com> wrote:
>>
>>> Justin,
>>>
>>> I took a look at the DAMap data structure & have some questions. What's
>>> the value of explicit methods for the top level of the structure? It is
>>> still possible to have name space collisions since there is nothing that
>>> prevents one module from writing into another module's "name space". Also,
>>> whats your expectation for locking? The top level accessor locks the
>>> structure, but modules that share the rest of the structure will have to do
>>> their own locking anyway. I guess one value of controlling the top level is
>>> that *IF* modules are making exclusive access to the structure, the locking
>>> is minimized. Hard to control that, though.
>>>
>>> Did you get a chance to look at the JsonStore structure? The path-based
>>> accessors are very different than providing immediate access to the OSDMap.
>>> As we discussed, I made that decision to support the synchronization
>>> operations (take & read) and it removes the exposed OSDMap so that the data
>>> structure can be replaced. I think the path-based accessor is probably too
>>> heavyweight for DAMap... well... maybe... given that we dont have any
>>> examples yet its hard to tell. :-)
>>>
>>> --mic
>>>
>>>
>>> On Mon, Feb 4, 2013 at 5:09 PM, Justin Clark-Casey <
>>> jjustincc at googlemail.com> wrote:
>>>
>>>> Okay, I have now merged this branch (dynamic-attributes2) to master.
>>>>  Please report any problems (or fix them :)
>>>>
>>>> As this is experimental functionality, if necessary it can be
>>>> changed/bug-fixed without any attempt to preserve existing data.  Any code
>>>> using it should handle the 'expected data not found' case anyway.
>>>>
>>>> On 26/01/13 19:52, Adams, Robert wrote:
>>>>
>>>>> This implementation will work for physics. The physics engine cannot
>>>>> reference Scene (circular reference madness) so, on creation of the scene's
>>>>> physics instance, I will pass in the instance of DAMap (since it is defined
>>>>> in OpenSim.Framework) much the same way the asset request method instance
>>>>> is passed in.
>>>>>
>>>>> I am +2 on this branch's inclusion into master.
>>>>>
>>>>> -- ra
>>>>>
>>>>> -----Original Message-----
>>>>> From: opensim-dev-bounces at lists.**berlios.de<opensim-dev-bounces at lists.berlios.de>[mailto:
>>>>> opensim-dev-bounces@**lists.berlios.de<opensim-dev-bounces at lists.berlios.de>]
>>>>> On Behalf Of Justin Clark-Casey
>>>>> Sent: Friday, January 25, 2013 5:14 PM
>>>>> To: opensim-dev at lists.berlios.de
>>>>> Subject: Re: [Opensim-dev] Dynamic attributes
>>>>>
>>>>> On 25/01/13 08:40, Oren Hurvitz wrote:
>>>>>
>>>>>> Ok, great. I hope all goes well and this will be added to master soon.
>>>>>>
>>>>>> What do you mean by "put the code in for MSSQL"? The code already
>>>>>> supports MySQL, MSSQL and SQLite.
>>>>>>
>>>>>
>>>>> Apologies - my brain stored the assumption that only MySQL had been
>>>>> added since that's the only one I remembered seeing in the commit summaries
>>>>> but I see that the MSSQL code is there.
>>>>>
>>>>> --
>>>>> Justin Clark-Casey (justincc)
>>>>> OSVW Consulting
>>>>> http://justincc.org
>>>>> http://twitter.com/justincc
>>>>> ______________________________**_________________
>>>>> Opensim-dev mailing list
>>>>> Opensim-dev at lists.berlios.de
>>>>> https://lists.berlios.de/**mailman/listinfo/opensim-dev<https://lists.berlios.de/mailman/listinfo/opensim-dev>
>>>>> ______________________________**_________________
>>>>> Opensim-dev mailing list
>>>>> Opensim-dev at lists.berlios.de
>>>>> https://lists.berlios.de/**mailman/listinfo/opensim-dev<https://lists.berlios.de/mailman/listinfo/opensim-dev>
>>>>>
>>>>>
>>>>
>>>> --
>>>> Justin Clark-Casey (justincc)
>>>> OSVW Consulting
>>>> http://justincc.org
>>>> http://twitter.com/justincc
>>>> ______________________________**_________________
>>>> Opensim-dev mailing list
>>>> Opensim-dev at lists.berlios.de
>>>> https://lists.berlios.de/**mailman/listinfo/opensim-dev<https://lists.berlios.de/mailman/listinfo/opensim-dev>
>>>>
>>>
>>>
>>
> 
> 
> 
> _______________________________________________
> Opensim-dev mailing list
> Opensim-dev at lists.berlios.de
> https://lists.berlios.de/mailman/listinfo/opensim-dev