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