<div dir="ltr"><div>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.</div><div><br></div>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.<div><br></div><div>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.</div><div><br></div><div>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.</div><div><br></div><div>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.</div><div><br></div><div>Oren</div><div><br></div><div><br></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Fri, Dec 19, 2014 at 2:29 AM, Diva Canto <span dir="ltr"><<a href="mailto:diva@metaverseink.com" target="_blank">diva@metaverseink.com</a>></span> wrote:<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div bgcolor="#FFFFFF" text="#000000">
<div>+1 on this going to core.<br>
<br>
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.<div><div class="h5"><br>
<br>
On 12/18/2014 4:11 PM, Mic Bowman wrote:<br>
</div></div></div>
<blockquote type="cite"><div><div class="h5">
<div dir="ltr">i've had several requests for the dispatcher
interface to be moved into core. dispatcher package consists of
two pieces:
<div><br>
</div>
<div>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). </div>
<div><br>
</div>
<div><a href="https://github.com/cmickeyb/scisim-addons/tree/master/dispatcher" target="_blank">https://github.com/cmickeyb/scisim-addons/tree/master/dispatcher</a><br>
</div>
<div><br>
</div>
<div>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). </div>
<div><br>
<div><a href="https://github.com/cmickeyb/scisim-addons/tree/master/rcontrol" target="_blank">https://github.com/cmickeyb/scisim-addons/tree/master/rcontrol</a></div>
<div><br>
</div>
<div>for more information on what the dispatcher is and why
you might want to use it, watch the OSCC presentation <a href="http://www.ustream.tv/recorded/55195110" target="_blank">http://www.ustream.tv/recorded/55195110</a>
or take a look at the kinds of scripts that you can write by
looking in the scripts directory of the rcontrol repository.</div>
<div><br>
</div>
<div>with all that said... </div>
<div><br>
</div>
<div>i would like to start the discussion about whether this
is useful enough to be moved into core & how that should
happen.</div>
<div><br>
</div>
<div>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.</div>
<div><br>
</div>
<div>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.</div>
<div><br>
</div>
<div>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.</div>
<div><br>
</div>
<div>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). </div>
<div><br>
</div>
<div>--mic<br>
</div>
<div><br>
</div>
<div>
<div><br>
</div>
</div>
</div>
</div>
<br>
<fieldset></fieldset>
<br>
</div></div><pre>_______________________________________________
Opensim-dev mailing list
<a href="mailto:Opensim-dev@opensimulator.org" target="_blank">Opensim-dev@opensimulator.org</a>
<a href="http://opensimulator.org/cgi-bin/mailman/listinfo/opensim-dev" target="_blank">http://opensimulator.org/cgi-bin/mailman/listinfo/opensim-dev</a>
</pre>
</blockquote>
<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 clear="all"><div><br></div>-- <br><div class="gmail_signature"><div dir="ltr">Oren Hurvitz<br>VP R&D<br>Kitely Ltd.<br><br>Email: <a href="mailto:orenh@kitely.com" target="_blank">orenh@kitely.com</a><a href="mailto:ilan@kitely.com" target="_blank"></a></div></div>
</div>