[Opensim-dev] Add a JsonTestStore() for the JSON store module?
Mic Bowman
cmickeyb at gmail.com
Thu Jan 31 17:23:11 UTC 2013
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.
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.
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.
list tags = JsonGetHashTags(kstoreID,path);
integer length = JsonGetArrayLength(kstoreID,path);
By the way, I updated the wiki page on the json store to cover path syntax.
--mic
On Wed, Jan 30, 2013 at 9:06 PM, Justin Clark-Casey <
jjustincc at googlemail.com> wrote:
> Thanks Mic. Sorry I wasn't around earlier - schedule has gone massively
> late again (and I'm probably offline thurs).
>
> I'm not an LSL expert, but I think the classic 'LSL' way to do this would
> be to return a strided list [1].
>
> Maybe something like
>
> JsonGetValues(key storeID, string path):list
> JsonGetValuesJson(key storeID, string path):list
>
> So
>
> list stridedVals = JsonGetValues(storeID, "foo[*].bar");
>
> to get something like
>
> ["foo[0].bar", "hello", "foo[1].bar", "world", ... ]
>
> Then one can use functions like llList2ListStrided to get just the values
> as desired, e.g.
>
> list result_a = llList2ListStrided(**stridedVals, 0, -1, 2);
> // result_a == [ "hello", "world" ]
>
> 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).
>
> 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.
>
> Also, a couple of other questions, which might just be due to my ignorance
> of not having looked at the code deeply enough yet.
>
> * 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?
>
> * 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?
>
> [1] http://wiki.secondlife.com/**wiki/Category:LSL_List#**Strided_lists<http://wiki.secondlife.com/wiki/Category:LSL_List#Strided_lists>
> [2] http://goessner.net/articles/**JsonPath/<http://goessner.net/articles/JsonPath/>
> [3] http://projects.plural.cc/**projects/jsonij/wiki/JPath<http://projects.plural.cc/projects/jsonij/wiki/JPath>
>
>
>
> On 30/01/13 22:48, Mic Bowman wrote:
>
>> Done.
>>
>>
>> On Wed, Jan 30, 2013 at 8:57 AM, Mic Bowman <cmickeyb at gmail.com <mailto:
>> cmickeyb at gmail.com>> wrote:
>>
>> I think that would be very useful. I can add it this afternoon, if
>> you don't beat me to it.
>>
>> When I wrote the interface to the Json store, I modeled the path
>> expansion after JQuery interface. However, I'm
>> finding that really challenging to use for iterating through an array
>> of values. Right now, I use osFormatString to
>> create the path dynamically. For example:
>>
>> integer i = 0;
>> while (i < 10)
>> {
>> string p = osFormatString("foo[{0}].bar",**[i]); // create path
>> "foo[0].bar"
>> string v = JsonGetValue(storeID,p);
>> }
>>
>> If you have any suggestions for a construct that would make the
>> iteration cleaner, I would be very interested. I've
>> bounced around (and written some test code) for taking a list (the
>> components of the path) as an argument, but
>> constructing the list is no easier than constructing the string. I've
>> also poked around with creating store handles
>> that point into an existing store (so you resolve the path "foo" into
>> a store handle then iterate at the top level).
>> Again, the code to walk through the structure is still excessively
>> complex.
>>
>> --mic
>>
>>
>>
>>
>> On Tue, Jan 29, 2013 at 10:03 PM, Justin Clark-Casey <
>> jjustincc at googlemail.com <mailto:jjustincc at googlemail.**com<jjustincc at googlemail.com>>>
>> wrote:
>>
>> Hi Mic. Whilst looking through these functions tonight, it
>> struck me that there doesn't appear to be a way to
>> tell if a certain JSON store still exists, as identified by its
>> key.
>>
>> Do you think it would be appropriate to add a function for that?
>> Perhaps JsonTestStore(), which is in keeping
>> with JsonTestPath()?
>>
>> --
>> Justin Clark-Casey (justincc)
>> OSVW Consulting
>> http://justincc.org
>> http://twitter.com/justincc
>> ______________________________**___________________
>> Opensim-dev mailing list
>> Opensim-dev at lists.berlios.de <mailto:Opensim-dev at lists.**
>> berlios.de <Opensim-dev at lists.berlios.de>>
>> https://lists.berlios.de/__**mailman/listinfo/opensim-dev<https://lists.berlios.de/__mailman/listinfo/opensim-dev><
>> 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/20130131/fa453dd0/attachment-0001.html>
More information about the Opensim-dev
mailing list