[Opensim-dev] dispatcher interface

[Melanie]

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 <melanie at t-data.com> 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 <dahliatrimble at gmail.com
>> >
>> > 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
>> > Opensim-dev at opensimulator.org
>> > http://opensimulator.org/cgi-bin/mailman/listinfo/opensim-dev
>> _______________________________________________
>> Opensim-dev mailing list
>> Opensim-dev at opensimulator.org
>> http://opensimulator.org/cgi-bin/mailman/listinfo/opensim-dev
>>
> 
> 
> 
> _______________________________________________
> Opensim-dev mailing list
> Opensim-dev at opensimulator.org
> http://opensimulator.org/cgi-bin/mailman/listinfo/opensim-dev