[Opensim-dev] dispatcher interface

[Dahlia Trimble]

Sure, I understand that replicating objects without explicit coding can be
very convenient and can also reduce errors. In my case however there is
usually very little in common between object structure in OpenSimulator and
whatever is on the other protocol endpoint and I usually just use each
message as a map. Even when javascript (which can create objects
dynamically) is used for an endpoint I end up using the objects as if they
were maps.

A typical scenario is a viewer with a hierarchical entity-component
scenegraph being mapped to SceneObjectGroup/SceneObjectPart. There is very
little in common between objects on either end.

Using the messages as maps allows for dynamic messages that don't usually
require a recompile for trivial changes. This is a strength of LLSD/OSD and
was a design goal. I can see how others may prefer something hard coded
such as protocol buffers for some applications but in my case the value of
a dynamic protocol outweighed any gains I would have got from protocol
buffers (which I did evaluate).

On Tue, Dec 23, 2014 at 5:25 PM, Mic Bowman <cmickeyb at gmail.com> 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
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://opensimulator.org/pipermail/opensim-dev/attachments/20141223/9c98d25f/attachment.html>