[Opensim-dev] dispatcher interface

[Mister Blue]

I'd like the dispatcher interface in core as it could become the basis for
a secure, layered, extensible interface to start the replacement of the
existing rag-tag collection of other interfaces.

My other argument for core inclusion is that people move on. One reason we
have so many interfaces is that individuals create some feature and, after
a time, move onto another project leaving the old code. If the dispatcher
interface was off in some git repository somewhere, eventually Mic will
become busy on other projects, people will start forking the sources,
features and versions will scatter around the Internet, and no one will
really know which to use. It would die a death of a thousand forks.

Whether to include the client libraries in core sounds like an echo of the
long running 'pure core' vs 'distribution' arguments. My personal feeling
is that 'core' should include everything for someone to install, configure,
manage, and run their own minimal grid. People who need to do more or
different are skilled enough to make the necessary changes. So, I'm for
inclusion of the clients as that would make the dispatcher part of the
complete package that is OpenSimulator.

-- mb

On Tue, Dec 23, 2014 at 10:31 PM, Mic Bowman <cmickeyb at gmail.com> wrote:

> i have no intention of converting to any XML-based format.
>
> On Tue, Dec 23, 2014 at 7:20 PM, Melanie <melanie at t-data.com> wrote:
>
>> 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
>> _______________________________________________
>> 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
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://opensimulator.org/pipermail/opensim-dev/attachments/20141225/9d05a1d2/attachment.html>