<div dir="ltr"><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Dec 23, 2014 at 5:03 PM, Dahlia Trimble <span dir="ltr"><<a href="mailto:dahliatrimble@gmail.com" target="_blank">dahliatrimble@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class=""><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><br><div class="gmail_quote"><span></span>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.</div></div></blockquote><div><br></div></span><div>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.</div></blockquote></div><br>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.</div><div class="gmail_extra"><br></div><div class="gmail_extra">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? </div><div class="gmail_extra"><br></div><div class="gmail_extra">Oh... and that doesn't even begin to touch the fact that we have some modules using xmlrpc (HG) and some using json. </div><div class="gmail_extra"><br></div><div class="gmail_extra">Justin is right that adding one more is probably not a good idea.</div><div class="gmail_extra"><br></div><div class="gmail_extra">--mic</div><div class="gmail_extra"><br></div><div class="gmail_extra"><br></div><div class="gmail_extra"><br></div></div>