[Opensim-dev] OpenSim Comms

[Cristina Videira Lopes]

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.

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.

Thoughts?

Crista