[Opensim-dev] OpenSim Comms

Sean Dague sdague at gmail.com
Sun Dec 28 04:37:34 UTC 2008


Cristina Videira Lopes wrote:
> Hi,
> 
> As some of you know I've been working on improving the sim-sim 
> ChildUpdate message to include a lot more information than what it has 
> now. This is needed for a variety of purposes, including improving 
> region crossings and TPs, but not only. In talking to Melanie and 
> Teravus, we decided that since this improvement is going to break 
> sim-sim comms anyway, it wouldn't be a bad idea to try something radical 
> and do this over HTTP POST instead of remoting.

It would be best if it was actually more properly REST, so using GET,
POST, PUT, and DELETE verbs depending on the direction the data is being
passed, and the updatable nature of it.  But, yes, moving to HTTP
instead of xml-rpc is a good idea.

> The good news is that I have this working. But before I commit anything 
> to trunk, I'd like to hear from you about OpenSim comms in general, and 
> their future. But I don't want this topic to degenerate in the 
> conversation about standalone vs. grid. I think that issue is marginal 
> here, since this is about remote sim-sim comms, independent of the UGAIM 
> services.
> 
>  From what I understand, everyone dislikes OGS1 for all sorts of 
> different reasons. From where I stand, Remoting in sim-sim comms is an 
> unnecessary tie to .Net. This HTTP POST method is really neat, I think, 
> and we could move all remote sim-sim comms to use HTTP POST, which will 
> make OpenSim  a lot more interoperable (yes, somebody might want to 
> write non-.Net simulator and have it talk to OpenSim :-).
> 
> But the real question is: should we *replace* the remoting methods in 
> OGS1 with this other thing, or should someone do some plugin magic in 
> order to be able to configure OpenSim with different communication 
> components?
> 
> To be very concrete. I started doing this new ChildAgentUpdate method as 
> a replacement of the existing one in OGS1. If I commit what I have, the 
> previous mechanism for ChildUpdates will disappear into svn history, and 
> this new one will pop up in the middle of Remoting (and XMLPRC, mind 
> you) methods. I'm not sure this is the right thing to do. An alternative 
> is to start another namespace called, say, OGS2, and rewrite all methods 
> that use remoting in OGS1 with methods in OGS2 that use HTTP POST. If I 
> do this, and without proper componentization, I'll have to do a similar 
> trick that I did for the HG, ie. make the comms configuration affect the 
> application classes themselves. But it's a little worse than for the HG, 
> because the data structures passed around are seriously intertwined 
> between Environment.Scenes and Comms. As we make improvements in those 
> data structures (as is the case in the ChildAgentUpdate message), we 
> need to change Environment.Scenes. Plus, regions using OGS1 won't work 
> with regions using OGS2.
> 
> So the even more real question is this: do we really want to make Comms 
> a replaceable component? Something that can be completely replaced under 
> the hood? If so, then componentizing it is a must, and the question is 
> how. If not, replacing OGS1 with another thing that serves as references 
> implementation of a standard protocol might be ok.

While modular is always good, honestly, a cleaner OGS2 based on HTTP
would make life much easier, and something that's been talked about for
at least a year.  I wouldn't worry too much on it forcing the
abandonment of OGS1.

One of the bits that would be really nice if it was possible in this
arena is to respect Content-type headers on the HTTP requests, allowing
serialization of the requests in different formats.  So it would be easy
to get an xml, json, or packed binary, depending on the interoperability
and speed requirements needed.

	-Sean

-- 
Sean Dague / Neas Bade
sdague at gmail.com
http://dague.net

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 252 bytes
Desc: OpenPGP digital signature
URL: <http://opensimulator.org/pipermail/opensim-dev/attachments/20081227/8a39d23f/attachment-0001.pgp>


More information about the Opensim-dev mailing list