On 21/12/14 06:36, Mic Bowman wrote:
2) example serialization -- there is an example in the document.
{
"$type": "Dispatcher.Messages.CreateCapabilityRequest",
"_AsyncRequest": false,
"_Capability": "a1b108dc-11aa-44cb-a971-760dbadef07c",
"_Domain": "Dispatcher",
"_Scene": "Test Region",
"DomainList": ["Dispatcher", "RemoteControl"],
"FirstName": "Test",
"LastName": "User",
"HashedPasswd": "99cafb4ff0e3a8a6708f3854b713b552",
"LifeSpan": 300,
"UserID": "16d0f788-2066-4b64-b248-ffa239f62240"
}
So, an issue here on any use over untrusted networks (i.e. the internet) may be continual sending of an MD5 password,
which for any common password will not be hard to crack.
That said, default login over http is currently worse.
In both cases, it should really be necessary, quite possibly mandatory, to use https though that involves setting up the
probably self-signed cert, etc. I think Teravus implemented that for login but I have never got round to digging up the
details.
3) a new communication
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.
That's true, but I don't think that's an argument for continuing to do it. Do you think it's reasonable to always have
a hodge-podge of entirely different calling formats for different facilities where there is no technical reason for them
to be different? I'm not saying dispatcher has to be changed but if it isn't then I think we should have some agreement
that this kind of approach should be used for future similar interfacing facilities, not something different every
single time.
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.
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.
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.
I do appreciate your argument. As Tommy mentioned, there is NuGet but I'm not sure how mature it is for Mono or even
stuff outside Visual Studio (which seems to be its main use).
I would regard anything in the OpenSimulator tar.gz as part of core.
To me, among the problems with bundling client libraries with OpenSimulator are
1) Which languages? The last thing we need is a free-for-all.
2) Where do you stop? OpenSimulator has a large surface. I could put in all my code for interfacing with services, for
instance, where PHP made the most sense (ugh). Why not then extend to stats analysis code (written in Python)? Why not
then a web interface?
3) If someone wants to contribute then it has to be a core process and is very tied to OpenSimulator. I would argue
this discourages reimplementation in other servers and raises the bar where this might not otherwise be necessary.
Indeed, I have received a request to separate out pCampbot so ppl can work on it without being part of core. I don't
think this is unreasonable in the long run though it's non-trivial to do (it relies on opensim console stuff) and it
would have to be a decision agreed by core.
I'm not saying the kitchen sink approach is necessarily bad but I think either you do include a lot of stuff or very
little/none. I still prefer external repositories for client code, I don't think it's so bad and forces the
documentation to be better.
--mic
On Fri, Dec 19, 2014 at 6:16 PM, Justin Clark-Casey <[email protected]
<mailto:[email protected]>> wrote:
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
<http://opensimulator.org/wiki/Feature_Proposals>
[2] https://en.wikipedia.org/wiki/__Intel_Open_Source_License
<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
<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
<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
<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
<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] <mailto:[email protected]>
http://opensimulator.org/cgi-__bin/mailman/listinfo/opensim-__dev
<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] <mailto:[email protected]>
http://opensimulator.org/cgi-__bin/mailman/listinfo/opensim-__dev
<http://opensimulator.org/cgi-bin/mailman/listinfo/opensim-dev>
_______________________________________________
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
