[Opensim-dev] Dynamic attributes
Mic Bowman
cmickeyb at gmail.com
Fri Feb 8 16:59:26 UTC 2013
Putting limits on the JsonStore should not be too hard, it just hasn't been
a priority since the module is disabled by default. Since every update goes
through the interface (as opposed to DAMap where manipulation of the
structure under the "namespace" entry is completely hidden from the DAMap
structure) I think we could do some simple accounting that would keep
things from getting out of control ("perfect" limits to some size would be
much harder).
Also... the JsonStore structure currently limits values to strings for
simplicity (to avoid the typed version of functions like what you have with
the list accessors such as llList2Vector()). Its easy enough to convert
strings to the correct data type.
--mic
On Thu, Feb 7, 2013 at 5:39 PM, Justin Clark-Casey <jjustincc at googlemail.com
> wrote:
> I think this is a good point - if script access to dynamic attributes is
> every considered to be 'secure' (which might be a debatable point), one
> can't allow them to store indefinite amounts of data there. Even in an
> 'insecure' situation, it might be best to stop scripts being able to
> casually do this (which perhaps comes down to the debate I think that Mic
> and I were having about whether you assume the feature users are completely
> dumb or completely smart or try not to give them so much rope that they can
> easily accidentally hang themselves - I might be paraphrasing).
>
> The same thing is really true of the vanilla JsonStore since this is not
> limited either right now and could suck up all the memory even if its not
> persisted.
>
>
> On 07/02/13 02:11, Melanie wrote:
>
>> 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.**be**rlios.de <http://berlios.de><
>>>>>>> opensim-dev-bounces@**lists.berlios.de<opensim-dev-bounces at lists.berlios.de>
>>>>>>> >[mailto:
>>>>>>> opensim-dev-bounces@**lists.**berlios.de <http://lists.berlios.de><
>>>>>>> opensim-dev-**bounces at 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>
>>>>>>> <h**ttps://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>
>>>>>>> <h**ttps://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>
>>>>>> <h**ttps://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>
>>>
>> ______________________________**_________________
>> 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/20130208/8cb7d398/attachment-0001.html>
More information about the Opensim-dev
mailing list