<div dir="ltr">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.<div><br></div><div>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.</div><div><br></div><div>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.</div><div><br></div><div>-- mb</div></div><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Dec 23, 2014 at 10:31 PM, Mic Bowman <span dir="ltr"><<a href="mailto:cmickeyb@gmail.com" target="_blank">cmickeyb@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">i have no intention of converting to any XML-based format. </div><div class="gmail_extra"><br><div class="gmail_quote"><span class="">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:<br></span><div><div class="h5"><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><font color="#888888"><br>
Melanie<br>
</font></span><div><div><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" target="_blank">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" target="_blank">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" target="_blank">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" target="_blank">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" target="_blank">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" target="_blank">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></div><br></div>
<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></blockquote></div><br></div>