<div>The complexity and overhead of processing potentially large arrays using the strided lists just doesn't seem like an improvement. One of the advantages of the json store is that you can use "real" data structures and I'd rather not lose that by going back to converting into strided lists as the basis for data structures. </div>
<div><br></div><div>Another approach would be to extend the accessors from strings to lists. So ["foo.bar", 3, "value"] would be equivalent to "foo.bar[3].value". That would make it possible to create iterators with real integers. And it would be fairly easy to implement.</div>
<div><br></div><div>Another addition I would like to make... one function to get a list of keys from a hash node and one function to get the length of an array. </div><div><br></div><div>list tags = JsonGetHashTags(kstoreID,path);</div>
<div>integer length = JsonGetArrayLength(kstoreID,path);</div><div><br></div><div>By the way, I updated the wiki page on the json store to cover path syntax.</div><div><br></div><div>--mic</div><div><br></div><div><br><div class="gmail_quote">
On Wed, Jan 30, 2013 at 9:06 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">
Thanks Mic. Sorry I wasn't around earlier - schedule has gone massively late again (and I'm probably offline thurs).<br>
<br>
I'm not an LSL expert, but I think the classic 'LSL' way to do this would be to return a strided list [1].<br>
<br>
Maybe something like<br>
<br>
JsonGetValues(key storeID, string path):list<br>
JsonGetValuesJson(key storeID, string path):list<br>
<br>
So<br>
<br>
list stridedVals = JsonGetValues(storeID, "foo[*].bar");<br>
<br>
to get something like<br>
<br>
["foo[0].bar", "hello", "foo[1].bar", "world", ... ]<br>
<br>
Then one can use functions like llList2ListStrided to get just the values as desired, e.g.<br>
<br>
list result_a = llList2ListStrided(<u></u>stridedVals, 0, -1, 2);<br>
// result_a == [ "hello", "world" ]<br>
<br>
In this way, maybe one could even return the deeper structure by listing the full key for each value rather than the return serialized approach of the *Json() functions. Maybe this could be signalled as via an optional constant int flags field (in the same LSL way that things like osNpcCreate() take options).<br>
<br>
Strided lists are pretty horrible but at least people are familiar with them and there are various functions to help with handling them. I guess it's the only way to get any semblance of nested data structures in LSL.<br>
<br>
Also, a couple of other questions, which might just be due to my ignorance of not having looked at the code deeply enough yet.<br>
<br>
* I see there are many parallel *Json methods such as JsonGetValueJson(). I presume the natural way to parse serialized json returned from those (if one wanted) would be to temporarily create a store and then remove it?<br>
<br>
* Is the 'JPath' implementation the one at [2] or perhaps the one at [3] or something else entirely? How much of these 'specifications' is currently implemented?<br>
<br>
[1] <a href="http://wiki.secondlife.com/wiki/Category:LSL_List#Strided_lists" target="_blank">http://wiki.secondlife.com/<u></u>wiki/Category:LSL_List#<u></u>Strided_lists</a><br>
[2] <a href="http://goessner.net/articles/JsonPath/" target="_blank">http://goessner.net/articles/<u></u>JsonPath/</a><br>
[3] <a href="http://projects.plural.cc/projects/jsonij/wiki/JPath" target="_blank">http://projects.plural.cc/<u></u>projects/jsonij/wiki/JPath</a><div class="im"><br>
<br>
<br>
On 30/01/13 22:48, Mic Bowman wrote:<br>
</div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Done.<div class="im"><br>
<br>
On Wed, Jan 30, 2013 at 8:57 AM, Mic Bowman <<a href="mailto:cmickeyb@gmail.com" target="_blank">cmickeyb@gmail.com</a> <mailto:<a href="mailto:cmickeyb@gmail.com" target="_blank">cmickeyb@gmail.com</a>>> wrote:<br>
<br>
I think that would be very useful. I can add it this afternoon, if you don't beat me to it.<br>
<br>
When I wrote the interface to the Json store, I modeled the path expansion after JQuery interface. However, I'm<br>
finding that really challenging to use for iterating through an array of values. Right now, I use osFormatString to<br>
create the path dynamically. For example:<br>
<br>
integer i = 0;<br>
while (i < 10)<br>
{<br>
string p = osFormatString("foo[{0}].bar",<u></u>[i]); // create path "foo[0].bar"<br>
string v = JsonGetValue(storeID,p);<br>
}<br>
<br>
If you have any suggestions for a construct that would make the iteration cleaner, I would be very interested. I've<br>
bounced around (and written some test code) for taking a list (the components of the path) as an argument, but<br>
constructing the list is no easier than constructing the string. I've also poked around with creating store handles<br>
that point into an existing store (so you resolve the path "foo" into a store handle then iterate at the top level).<br>
Again, the code to walk through the structure is still excessively complex.<br>
<br>
--mic<br>
<br>
<br>
<br>
<br></div><div class="im">
On Tue, Jan 29, 2013 at 10:03 PM, Justin Clark-Casey <<a href="mailto:jjustincc@googlemail.com" target="_blank">jjustincc@googlemail.com</a> <mailto:<a href="mailto:jjustincc@googlemail.com" target="_blank">jjustincc@googlemail.<u></u>com</a>>> wrote:<br>
<br>
Hi Mic. Whilst looking through these functions tonight, it struck me that there doesn't appear to be a way to<br>
tell if a certain JSON store still exists, as identified by its key.<br>
<br>
Do you think it would be appropriate to add a function for that? Perhaps JsonTestStore(), which is in keeping<br>
with JsonTestPath()?<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></div>
______________________________<u></u>___________________<br>
Opensim-dev mailing list<br>
<a href="mailto:Opensim-dev@lists.berlios.de" target="_blank">Opensim-dev@lists.berlios.de</a> <mailto:<a href="mailto:Opensim-dev@lists.berlios.de" target="_blank">Opensim-dev@lists.<u></u>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">https://lists.berlios.de/<u></u>mailman/listinfo/opensim-dev</a>><div class="im">
<br>
<br>
<br>
<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>
<br>
</div></blockquote><div class="HOEnZb"><div class="h5">
<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>