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