[Opensim-dev] Dynamic attributes
Mic Bowman
cmickeyb at gmail.com
Thu Feb 7 01:59:39 UTC 2013
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>
>>>
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://opensimulator.org/pipermail/opensim-dev/attachments/20130206/cd164dc5/attachment-0001.html>
More information about the Opensim-dev
mailing list