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