for discussion purposes... <div><br></div><div>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"<div>
<br></div><div>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... </div>
<div><br></div><div>--mic</div><div><br><div><br></div><div><div>integer iChannel = 30;</div><div>string sInitCard = "JsonData";</div><div>key kStoreID;</div><div><br></div><div>InitializeObjectStore()</div><div>
{</div><div> llOwnerSay("initializing the object store");</div><div> JsonSetValueJson(kStoreID,"jstoretest","{'test1': {'field' : 22}}");</div><div> JsonReadNotecard(kStoreID,"jstoretest", sInitCard);</div>
<div>}</div><div><br></div><div>default </div><div>{</div><div> state_entry()</div><div> {</div><div> kStoreID = JsonAttachObjectStore();</div><div> if (JsonTestPathJson(kStoreID,"jstoretest") == 0)</div>
<div> InitializeObjectStore();</div><div><br></div><div> llOwnerSay("object store is " + JsonGetValueJson(kStoreID,"."));</div><div><br></div><div> llListen(iChannel,"",llGetOwner(),"");</div>
<div> }</div><div><br></div><div> listen(integer ch, string name, key id, string msg)</div><div> {</div><div> if (ch == iChannel)</div><div> {</div><div> list tokens = llParseString2List(msg,[" "],[]);</div>
<div> string path = JsonList2Path(tokens);</div><div> string value = JsonGetValueJson(kStoreID,path);</div><div> llOwnerSay(path + " == " + value);</div><div> }</div><div>
}</div><div>}</div><div><br></div><div><br><br><div class="gmail_quote">On Wed, Feb 6, 2013 at 3:00 PM, Mic Bowman <span dir="ltr"><<a href="mailto:cmickeyb@gmail.com" target="_blank">cmickeyb@gmail.com</a>></span> wrote:<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 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.<span class="HOEnZb"><font color="#888888"><div>
<br></div><div>--mic</div></font></span><div class="HOEnZb"><div class="h5"><div><br><div><br><div class="gmail_quote">On Wed, Feb 6, 2013 at 1:58 PM, Mic Bowman <span dir="ltr"><<a href="mailto:cmickeyb@gmail.com" target="_blank">cmickeyb@gmail.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Justin,<div><br></div><div>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.</div>
<div><br></div><div>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. :-)</div>
<span><font color="#888888">
<div><br></div><div>--mic</div></font></span><div><div><div><br><br><div class="gmail_quote">On Mon, Feb 4, 2013 at 5:09 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">Okay, I have now merged this branch (dynamic-attributes2) to master. Please report any problems (or fix them :)<br>
<br>
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.<br>
<br>
On 26/01/13 19:52, Adams, Robert wrote:<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 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.<br>
<br>
I am +2 on this branch's inclusion into master.<br>
<br>
-- ra<br>
<br>
-----Original Message-----<br>
From: <a href="mailto:opensim-dev-bounces@lists.berlios.de" target="_blank">opensim-dev-bounces@lists.<u></u>berlios.de</a> [mailto:<a href="mailto:opensim-dev-bounces@lists.berlios.de" target="_blank">opensim-dev-bounces@<u></u>lists.berlios.de</a>] 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>
<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>
</blockquote>
<br>
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.<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>
______________________________<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><span><font color="#888888">
</font></span></blockquote><span><font color="#888888">
<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>
</font></span></blockquote></div><br></div>
</div></div></blockquote></div><br></div></div>
</div></div></blockquote></div><br></div></div></div></div>