<div dir="ltr">I'll add some text to the feature proposal page. rather than dump all of the documentation i'm working on into the proposal, i've started a google site for documenting the behavior. we can move it to the opensim wiki later if that is appropriate: <a href="https://sites.google.com/site/opensimdispatcher/">https://sites.google.com/site/opensimdispatcher/</a><div><br></div><div>To answer your other questions...</div><div><br></div><div>1) authentication -- i'll finish the documentation for the authentication tomorrow. the gist is that every message must have a valid capability attached to it or the message will be rejected. a client can request the creation of a capability for an authenticated user account. there are criteria for limiting capabilities to estate managers or grid gods. i'm adding another filter for IP addresses.</div><div><br></div><div>2) example serialization -- there is an example in the document. </div><div><br></div><blockquote style="margin:0px 0px 0px 40px;border:none;padding:0px"><font face="monospace, monospace">{<br> "$type": "Dispatcher.Messages.CreateCapabilityRequest",<br> <br> "_AsyncRequest": false,<br> "_Capability": "a1b108dc-11aa-44cb-a971-760dbadef07c",<br> "_Domain": "Dispatcher",<br> "_Scene": "Test Region",<br> "DomainList": ["Dispatcher", "RemoteControl"],<br> "FirstName": "Test",<br> "LastName": "User",<br> "HashedPasswd": "99cafb4ff0e3a8a6708f3854b713b552",<br> "LifeSpan": 300,<br> "UserID": "16d0f788-2066-4b64-b248-ffa239f62240"<br>}</font></blockquote><div><font face="monospace, monospace"> </font></div><div><font face="arial, helvetica, sans-serif">the dispatcher's also provide an introspection interface. so the following will give you a message that contains a string representation of an instance of the requested message type:</font></div><div><font face="arial, helvetica, sans-serif"><br></font></div><div><font face="monospace, monospace">curl <a href="http://12.46.129.31:9002/Dispatcher/">http://12.46.129.31:9002/Dispatcher/</a> -d '{ "$type":"Dispatcher.Messages.MessageFormatRequest", "MessageName":"Dispatcher.Messages.CreateCapabilityRequest" }' -H "Content-Type: application/json"<br></font></div><div><font face="monospace, monospace"><br></font></div><div><font face="arial, helvetica, sans-serif">or you can request a list of supported messages with this command:</font></div><div><font face="monospace, monospace"><br></font></div><div><font face="monospace, monospace">curl <a href="http://12.46.129.31:9002/Dispatcher/">http://12.46.129.31:9002/Dispatcher/</a> -d '{ "$type":"Dispatcher.Messages.InfoRequest" }' -H "Content-Type: application/json"<br></font></div><div><font face="monospace, monospace"><br></font></div><div><font face="arial, helvetica, sans-serif">both of those commands are probing the dispatcher i'm running on the traffic simulation region i've made available.</font></div><div><font face="arial, helvetica, sans-serif"><br></font></div><div><font face="arial, helvetica, sans-serif">3) a new communication</font></div><div><font face="arial, helvetica, sans-serif"><br></font></div><div><font face="arial, helvetica, sans-serif">well... its never stopped us before. you forgot the stats interface, the remote administration interface, and the websocket interface. oh... and don't forget all the methods that LSL supports. i'm sure there are more. </font></div><div><font face="arial, helvetica, sans-serif"><br></font></div><div><font face="arial, helvetica, sans-serif">this is not a sim-to-sim communication module. its much more similar in intent to LSL or the remote admin interface. json-rpc is essentially identical. though the dispatcher requires some special format in order to map each of the json messages to a C# class. </font></div><div><font face="arial, helvetica, sans-serif"><br></font></div><div><font face="arial, helvetica, sans-serif">4 there would only be C# in core. the only non-C# code is the client libraries which may or may not be distributed with core. they are not built or compiled as part of building or installing opensim. its more like distributing a bunch of assets for an avatar's library. </font></div><div><font face="arial, helvetica, sans-serif"><br></font></div><div><font face="arial, helvetica, sans-serif">all that being said... if we actually had a reasonable distribution mechanism we wouldn't be having this conversation because many (most) of the modules we package as optional modules should be loaded dynamically. something like PyIP or CPAN. but we don't have one of those. </font></div><div><font face="arial, helvetica, sans-serif"><br></font></div><div><font face="arial, helvetica, sans-serif">so my question is... what's the point of putting it in core at all if we going to require anyone who uses it to go digging for client libraries from some other site? while someone could generate their own json libraries, the effort of putting it in core is really not worth it for the *very* small number of people who will do that. on the other hand... if there are some useful commands already distributed with core (in a utility director or something), then we have added value. </font></div><div><font face="arial, helvetica, sans-serif"><br></font></div><div><font face="arial, helvetica, sans-serif">5. documentation. see above. working on it.</font></div><div><font face="arial, helvetica, sans-serif"><br></font></div><div><font face="arial, helvetica, sans-serif">6. definitely turn it off by default. the site i pointed to has an example configuration (which is also included in the github repository.</font></div><div><font face="arial, helvetica, sans-serif"><br></font></div><div><font face="arial, helvetica, sans-serif">7. license... just copied with the Intel lawyers gave me when I asked. remember that this has been used extensively by me for four years. and... like all intel contributions, we would replace the license with the opensim standard license.</font></div><div><font face="arial, helvetica, sans-serif"><br></font></div><div><font face="arial, helvetica, sans-serif">--mic</font></div><div><font face="arial, helvetica, sans-serif"><br></font></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Fri, Dec 19, 2014 at 6:16 PM, Justin Clark-Casey <span dir="ltr"><<a href="mailto:jjustincc@googlemail.com" target="_blank">jjustincc@googlemail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">I would be happy to see this in core. I do have the following questions/points. I would ideally like to see much of this stuff in a feature proposal page [1] and that can later also become some documentation.<br>
<br>
1. Please could you go into detail about the authentication/access model. Looking over the code, I see text about domains, capabilities, authentication by hashed password, etc. but I would like an overview on how this fits together.<br>
<br>
2. Please could you give an example serialization of one of the JSON messages. I would like to see the basic form and what one expects to see in such a message.<br>
<br>
3. This would be yet another different kind of message passing in OpenSimulator, to join XMLRPC, JSON RPC, form, etc, where the majority of internal communication is via XMLRPC. I'm not saying we should persist with XMLRPC in this case, but I would really like to see some agreement on how communication should evolve in the future, whether that should be JSON/BSON or something else.<br>
<br>
4. I don't feel that we should change our rule of only having C# code in core. Having other languages or client code increases project complexity and implies a commitment to maintain code which is not part of the server system (hence I think one could make a case for separating out pCampbot but that's another topic). I think it's fine for the client code to be external as long as there are open-source clients under a permissive license (Vivox being a historical exception) and the interfaces are documented.<br>
<br>
5. Regarding documentation, to be clear I think wiki pages will be required documenting the general approach, security model, etc.<br>
<br>
6. In this case, I don't think that this facility should be enabled by default as it does expose a method of interacting with the simulator with security implications, even on a private network.<br>
<br>
7. I see all the license notices are BSD but with an extra "EXPORT LAWS" text which I find rather bizarre as it purports to add "NO RESTRICTIONS TO THE EXPORT LAWS OF YOUR JURISDICTION". I find this rather bizarre (why have such a paragraph if it doesn't do anything?). Apparantly, Intel itself has ceased to use or recommend this license text [2] and has asked the OSI to remove it for future use as an approved license back in 2005 [3]. Is it going to be a problem to remove this text before adding any code into core?<br>
<br>
[1] <a href="http://opensimulator.org/wiki/Feature_Proposals" target="_blank">http://opensimulator.org/wiki/<u></u>Feature_Proposals</a><br>
[2] <a href="https://en.wikipedia.org/wiki/Intel_Open_Source_License" target="_blank">https://en.wikipedia.org/wiki/<u></u>Intel_Open_Source_License</a><br>
[3] <a href="http://news.cnet.com/Intel-to-stop-using-open-source-license/2100-7344_3-5648518.html" target="_blank">http://news.cnet.com/Intel-to-<u></u>stop-using-open-source-<u></u>license/2100-7344_3-5648518.<u></u>html</a><div><div class="h5"><br>
<br>
On 19/12/14 00:11, Mic Bowman wrote:<br>
</div></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div><div class="h5">
i've had several requests for the dispatcher interface to be moved into core. dispatcher package consists of two pieces:<br>
<br>
dispatcher -- the core modules that implement the message transfer, message encoding and some of the basic messages<br>
(informational messages and 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 remote scripting API. these messages include some<br>
basics for accessing/creating assets, for getting/setting avatar appearance, sending messages, managing objects in the<br>
scene, and managing some of the region characteristics. there are also messages for registering remote handlers for<br>
touch events. clearly this is just a start (though there is a 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 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 scripts that you can write by looking in the<br>
scripts directory of the rcontrol repository.<br>
<br>
with all that said...<br>
<br>
i would like to start the discussion about whether this is useful enough 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 benefits to both. its easier for me to change<br>
for my purposes if if its outside core and its (much) easier for the community to use it if its in core. if the<br>
community believes there is sufficient value, then we should move it in.<br>
<br>
if it is not moved inside, i would appreciate suggestions on how to distribute the libraries. this is an ongoing problem<br>
for opensim... how to provide simple access to a dynamic set of region modules. probably a bigger discussion.<br>
<br>
if we think the dispatcher API should be moved into core, then there are a few questions about how that should happen.<br>
clearly the region modules can be moved into OpenSim/Region/<u></u>OptionalModules. that's easy. the more interesting question<br>
is where to put the client libraries (these are the perl & python libraries that are used to build dispatcher clients)<br>
and the control scripts that are rather useful for managing a region. I would propose placing them in a directory under<br>
OpenSim/Tools though they really 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 pseudo-self documenting... the API lets you can ask any<br>
simulator for the messages it supports & then ask for examples of the messages themselves. i'm planning to add a<br>
"documentation" string for each as well. some other methods for autodoc would be useful though pulling out dispatcher<br>
documentation from within the multitude of existing opensim autodoc might be challenging (not something i have any<br>
experience with).<br>
<br>
--mic<br>
<br>
<br>
<br>
<br></div></div><span class="">
______________________________<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>
</span></blockquote><span class="HOEnZb"><font color="#888888">
<br>
<br>
-- <br>
Justin Clark-Casey (justincc)<br>
OSVW Consulting<br>
<a href="http://justincc.org" target="_blank">http://justincc.org</a><br>
<a href="http://twitter.com/justincc" target="_blank">http://twitter.com/justincc</a></font></span><div class="HOEnZb"><div class="h5"><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>
</div></div></blockquote></div><br></div>