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 <[email protected]> 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 > >> [email protected]http://opensimulator.org/cgi-bin/mailman/listinfo/opensim-dev > >> > >> > >> > >> _______________________________________________ > >> Opensim-dev mailing list > >> [email protected] > >> http://opensimulator.org/cgi-bin/mailman/listinfo/opensim-dev > >> > >> > > > > > > > > _______________________________________________ > > Opensim-dev mailing list > > [email protected] > > http://opensimulator.org/cgi-bin/mailman/listinfo/opensim-dev > _______________________________________________ > Opensim-dev mailing list > [email protected] > http://opensimulator.org/cgi-bin/mailman/listinfo/opensim-dev _______________________________________________ Opensim-dev mailing list [email protected] http://opensimulator.org/cgi-bin/mailman/listinfo/opensim-dev
