<div dir="ltr">No "thrust" intended on my part :) I'm just sharing notes as someone who has implemented a similar framework.<br><br></div><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Dec 23, 2014 at 7:20 PM, Melanie <span dir="ltr"><<a href="mailto:melanie@t-data.com" target="_blank">melanie@t-data.com</a>></span> wrote:<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Actually, I meant to say "hate". Regardless, I am not complaining<br>
about the way the JSON is created but more about the thrust i read<br>
in the undercurrent of the prior emails to make the interface LLSD<br>
like everything else. That I am opposed to.<br>
<span class="HOEnZb"><font color="#888888"><br>
Melanie<br>
</font></span><div class="HOEnZb"><div class="h5"><br>
On 24/12/2014 04:12, Dahlia Trimble wrote:<br>
> OSD has serializations for XML, JSON, Notation, and binary as per the LLSD<br>
> documentation.<br>
><br>
> On Tue, Dec 23, 2014 at 7:08 PM, Melanie <<a href="mailto:melanie@t-data.com">melanie@t-data.com</a>> wrote:<br>
>><br>
>> I would have to see this become OSD XML (LLXML( because LLXML is so<br>
>> much wordier (up to 100% size gain on small messages, like one<br>
>> acknowledgement byte. JSON is superior in pretty much every way<br>
>> except for enforced typing and I don't judge that valuable enough to<br>
>> let it double the message byte size.<br>
>><br>
>> Melanie<br>
>><br>
>> On 24/12/2014 02:25, Mic Bowman wrote:<br>
>> > On Tue, Dec 23, 2014 at 5:03 PM, Dahlia Trimble <<a href="mailto:dahliatrimble@gmail.com">dahliatrimble@gmail.com</a><br>
>> ><br>
>> > wrote:<br>
>> ><br>
>> >><br>
>> >>> Show me a mechanism in opensim that is well layered enough to handle<br>
>> >>> these messages with both binary & text encoding over both streaming &<br>
>> >>> packet protocols and i will gladly use it.<br>
>> >>><br>
>> >><br>
>> >> I used the libomv OSD and it's various serializations. They worked very<br>
>> >> well. I've found the JSON to be quite usable with python, javascript<br>
>> ,and a<br>
>> >> few c++ libs I've tried.  I've not had as good of luck with the various<br>
>> >> binary LLSD ports out there though and I wrote my own for c++. I've used<br>
>> >> the various serializations both in TCP and UDP with good success.<br>
>> >><br>
>> ><br>
>> > I don't think the JSON encoding is the problem. There is JSON all over.<br>
>> > JSON RPC. JSON for submitting simulator to simulator messages. Most are<br>
>> > using the OSD serializer for it. I personally use Newtonsoft because 1)<br>
>> its<br>
>> > significantly faster and 2) it can re-ify into object classes easily<br>
>> > (meaning that the json can be converted transparently into an C# object<br>
>> of<br>
>> > a specific per-message-type class without great big switch statements).<br>
>> The<br>
>> > reification is convenient for me because it means that the message<br>
>> handlers<br>
>> > dont care how the messages came in (abstraction for layering, means I can<br>
>> > replace the JSON encoding with anything that builds the classes in a<br>
>> > consistent way) & they don't have to dig through multiple levels of<br>
>> > dictionaries to find a particular value (enforcement of the structure).<br>
>> If<br>
>> > I want to add a new method of security, I only have one place i need to<br>
>> > change.<br>
>> ><br>
>> > That being said... the problem is that there is no consistency in the use<br>
>> > of json. Some times we encode the method in the body of the json,<br>
>> sometimes<br>
>> > in the url. Sometimes the decoding happens in a module (see<br>
>> > NeighbourHandlers). Sometimes it happens in the HTTP server handlers<br>
>> (JSON<br>
>> > RPC). Lets just say that we wanted to actually add a method for<br>
>> authorizing<br>
>> > messages to ensure that they come from an adjacent simulator... where<br>
>> would<br>
>> > you make the change?<br>
>> ><br>
>> > Oh... and that doesn't even begin to touch the fact that we have some<br>
>> > modules using xmlrpc (HG) and some using json.<br>
>> ><br>
>> > Justin is right that adding one more is probably not a good idea.<br>
>> ><br>
>> > --mic<br>
>> ><br>
>> ><br>
>> ><br>
>> ><br>
>> > _______________________________________________<br>
>> > Opensim-dev mailing list<br>
>> > <a href="mailto:Opensim-dev@opensimulator.org">Opensim-dev@opensimulator.org</a><br>
>> > <a href="http://opensimulator.org/cgi-bin/mailman/listinfo/opensim-dev" target="_blank">http://opensimulator.org/cgi-bin/mailman/listinfo/opensim-dev</a><br>
>> _______________________________________________<br>
>> Opensim-dev mailing list<br>
>> <a href="mailto:Opensim-dev@opensimulator.org">Opensim-dev@opensimulator.org</a><br>
>> <a href="http://opensimulator.org/cgi-bin/mailman/listinfo/opensim-dev" target="_blank">http://opensimulator.org/cgi-bin/mailman/listinfo/opensim-dev</a><br>
>><br>
><br>
><br>
><br>
> _______________________________________________<br>
> Opensim-dev mailing list<br>
> <a href="mailto:Opensim-dev@opensimulator.org">Opensim-dev@opensimulator.org</a><br>
> <a href="http://opensimulator.org/cgi-bin/mailman/listinfo/opensim-dev" target="_blank">http://opensimulator.org/cgi-bin/mailman/listinfo/opensim-dev</a><br>
_______________________________________________<br>
Opensim-dev mailing list<br>
<a href="mailto:Opensim-dev@opensimulator.org">Opensim-dev@opensimulator.org</a><br>
<a href="http://opensimulator.org/cgi-bin/mailman/listinfo/opensim-dev" target="_blank">http://opensimulator.org/cgi-bin/mailman/listinfo/opensim-dev</a><br>
</div></div></blockquote></div></div>