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.
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.
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.
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.
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.
5. Regarding documentation, to be clear I think wiki pages will be required documenting the general approach, security
model, etc.
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.
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?
[1] http://opensimulator.org/wiki/Feature_Proposals
[2] https://en.wikipedia.org/wiki/Intel_Open_Source_License
[3]
http://news.cnet.com/Intel-to-stop-using-open-source-license/2100-7344_3-5648518.html
On 19/12/14 00:11, 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 list
[email protected]
http://opensimulator.org/cgi-bin/mailman/listinfo/opensim-dev
--
Justin Clark-Casey (justincc)
OSVW Consulting
http://justincc.org
http://twitter.com/justincc
_______________________________________________
Opensim-dev mailing list
[email protected]
http://opensimulator.org/cgi-bin/mailman/listinfo/opensim-dev
