[Opensim-dev] dispatcher interface

Fri Dec 19 15:47:08 UTC 2014

I would prefer to see the server-side in core and the clients in a
separate place. Python uses pip, Perl uses CPAN, etc. to manage
applications. I would be all-for a git repository of clients on
opensimulator.org. Maybe an API versioning scheme could help keep
clients in sync with the server API version.

-BlueWall

On Fri, 2014-12-19 at 16:37 +0100, Melanie wrote:
> This is a very real issue - in the past packages have been refused
> core inclusion and packages have even been removed for using
> languages other than C#. Can of worms here. Do we want to lift the
> requirement, or do we want to have only the C# based dispatcher in
> core but not the clients?
> 
> Melanie
> 
> 
> On 19/12/2014 06:11, Oren Hurvitz wrote:
> > I would also like to see Dispatcher in core: it opens up many interesting
> > possibilities, and it's a good example of things OpenSim can do that SL
> > can't.
> > 
> > Adding Dispatcher to core would make it easier to keep it up-to-date
> > whenever the API changes, since any changes to an interface that Dispatcher
> > uses would cause a compilation error so it would get fixed immediately.
> > 
> > The clients should also go into the main OpenSim repository, because
> > they're strongly coupled with Dispatcher: whenever Dispatcher changes the
> > clients also need to change. If they're stored in a different repository
> > then it's likely that the clients would drift out of sync with the part of
> > Dispatcher that's in the main OpenSim repository.
> > 
> > There's a challenge with the clients, however: since they're in multiple
> > languages, does that mean that anyone who wants to change Dispatcher also
> > has to know all of these languages, so that they can update the clients?
> > That's a high bar. I think we're looking at a situation similar to the
> > database engines: since most developers only use one database engine
> > (usually SQLite or MySQL), the popular engines are kept up-to-date while
> > less-popular engines (SQL Server, Postgres) aren't updated in a timely
> > manner. Basically, they're only updated when their champion realizes that
> > something is broken and brings them up to spec.
> > 
> > I don't mean to create even MORE work for you, Mic, but is it possible to
> > create some sort of client bindings that are automatically generated from a
> > common API? That way, perhaps all devs have to know is to run something
> > like "ant rebuild-dispatcher-clients" and they'd get updated immediately.
> > If that's not possible then at least a stern warning in the Dispatcher code
> > should exhort developers to try and keep the clients up to date.
> > 
> > Oren
> > 
> > 
> > 
> > On Fri, Dec 19, 2014 at 2:29 AM, Diva Canto <diva at metaverseink.com> wrote:
> >>
> >>  +1 on this going to core.
> >>
> >> WRT client code, I suggest that you leave it in your github repo and point
> >> to it. That way we don't confuse people with having code in other languages
> >> in core opensim.
> >>
> >>
> >> On 12/18/2014 4:11 PM, Mic Bowman wrote:
> >>
> >> i've had several requests for the dispatcher interface to be moved into
> >> core. dispatcher package consists of two pieces:
> >>
> >>  dispatcher -- the core modules that implement the message transfer,
> >> message encoding and some of the basic messages (informational messages and
> >> messages to create and renew access capabilities).
> >>
> >>  https://github.com/cmickeyb/scisim-addons/tree/master/dispatcher
> >>
> >>  remote control -- a collection of messages that implement a OpenSim
> >> remote scripting API. these messages include some basics for
> >> accessing/creating assets, for getting/setting avatar appearance, sending
> >> messages, managing objects in the scene, and managing some of the region
> >> characteristics. there are also messages for registering remote handlers
> >> for touch events. clearly this is just a start (though there is a
> >> surprisingly large number of things you can do with these).
> >>
> >> https://github.com/cmickeyb/scisim-addons/tree/master/rcontrol
> >>
> >>  for more information on what the dispatcher is and why you might want to
> >> use it, watch the OSCC presentation
> >> http://www.ustream.tv/recorded/55195110 or take a look at the kinds of
> >> scripts that you can write by looking in the scripts directory of the
> >> rcontrol repository.
> >>
> >>  with all that said...
> >>
> >>  i would like to start the discussion about whether this is useful enough
> >> to be moved into core & how that should happen.
> >>
> >>  i don't have a particular stake in whether its moved to core. there are
> >> benefits to both. its easier for me to change for my purposes if if its
> >> outside core and its (much) easier for the community to use it if its in
> >> core. if the community believes there is sufficient value, then we should
> >> move it in.
> >>
> >>  if it is not moved inside, i would appreciate suggestions on how to
> >> distribute the libraries. this is an ongoing problem for opensim... how to
> >> provide simple access to a dynamic set of region modules. probably a bigger
> >> discussion.
> >>
> >>  if we think the dispatcher API should be moved into core, then there are
> >> a few questions about how that should happen. clearly the region modules
> >> can be moved into OpenSim/Region/OptionalModules. that's easy. the more
> >> interesting question is where to put the client libraries (these are the
> >> perl & python libraries that are used to build dispatcher clients) and the
> >> control scripts that are rather useful for managing a region. I would
> >> propose placing them in a directory under OpenSim/Tools though they really
> >> aren't tools in the sense of the other packages in that directory.
> >>
> >>  the final question is about documentation. the api is already
> >> pseudo-self documenting... the API lets you can ask any simulator for the
> >> messages it supports & then ask for examples of the messages themselves.
> >> i'm planning to add a "documentation" string for each as well. some other
> >> methods for autodoc would be useful though pulling out dispatcher
> >> documentation from within the multitude of existing opensim autodoc might
> >> be challenging (not something i have any experience with).
> >>
> >>  --mic
> >>
> >>
> >>
> >>
> >> _______________________________________________
> >> Opensim-dev mailing listOpensim-dev at opensimulator.orghttp://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