I think we should use REST for most of the comms, but am a little bit wary about if it will be the right choice for some of the region to region comms. And if the overhead in lots of http requests/posts will be too much, for messages like ChildAgentUpdate that we should be sending quite often. <br><br>As for making comms a Region module, I'm +1 to that sort of idea. In the past I have from time to time, gone through removing direct references from scene, and region modules to the comms manager and instead routing them through wrapper functions in SceneCommunicationService. So that at some point we could refactor it to remove the current comms manager and make SceneCommunicationService into some sort of region module. <br><br>I know that recently we have started taking the reverse course and removing the wrapper function. Which also has its benefits as there isn't much point in having the wrapper if we keep the comms manager as it is.<br><br><br>But anyway to answer your
 questions, if you have a REST childagentUpdate working and its a improvement on what we have, then I'd say that there shouldn't be any problem with replacing the old method as the way to get it in the quickest.<br><br>But I think we really should have some better method to do comms plugin replacement/configuration in the future, weather that is by having it as a region module, or just improving the current system. So if you want to do that now, then I think that would be great.<br><br><br><b><i>Melanie <melanie@t-data.com></i></b> wrote:<blockquote class="replbq" style="border-left: 2px solid rgb(16, 16, 255); margin-left: 5px; padding-left: 5px;"> Hi,<br><br>I have made my view widely known already:<br><br>I'm for REST and the idea about making it choose the most efficient <br>format sounds like a winner to me.<br><br>I would like to see comms become a region module instead of the <br>tightly tied OGS1 we have now, or a replacement OGS2. That way, any <br>method of
 communication can be implemented, including a null method <br>for local operation only, and it can be done easily and without <br>messing with existing code at that point.<br><br>Melanie<br><br><br>Cristina Videira Lopes wrote:<br>> Hi,<br>> <br>> As some of you know I've been working on improving the sim-sim <br>> ChildUpdate message to include a lot more information than what it has <br>> now. This is needed for a variety of purposes, including improving <br>> region crossings and TPs, but not only. In talking to Melanie and <br>> Teravus, we decided that since this improvement is going to break <br>> sim-sim comms anyway, it wouldn't be a bad idea to try something radical <br>> and do this over HTTP POST instead of remoting.<br>> <br>> The good news is that I have this working. But before I commit anything <br>> to trunk, I'd like to hear from you about OpenSim comms in general, and <br>> their future. But I don't want this topic
 to degenerate in the <br>> conversation about standalone vs. grid. I think that issue is marginal <br>> here, since this is about remote sim-sim comms, independent of the UGAIM <br>> services.<br>> <br>>  From what I understand, everyone dislikes OGS1 for all sorts of <br>> different reasons. From where I stand, Remoting in sim-sim comms is an <br>> unnecessary tie to .Net. This HTTP POST method is really neat, I think, <br>> and we could move all remote sim-sim comms to use HTTP POST, which will <br>> make OpenSim  a lot more interoperable (yes, somebody might want to <br>> write non-.Net simulator and have it talk to OpenSim :-).<br>> <br>> But the real question is: should we *replace* the remoting methods in <br>> OGS1 with this other thing, or should someone do some plugin magic in <br>> order to be able to configure OpenSim with different communication <br>> components?<br>> <br>> To be very concrete. I started doing
 this new ChildAgentUpdate method as <br>> a replacement of the existing one in OGS1. If I commit what I have, the <br>> previous mechanism for ChildUpdates will disappear into svn history, and <br>> this new one will pop up in the middle of Remoting (and XMLPRC, mind <br>> you) methods. I'm not sure this is the right thing to do. An alternative <br>> is to start another namespace called, say, OGS2, and rewrite all methods <br>> that use remoting in OGS1 with methods in OGS2 that use HTTP POST. If I <br>> do this, and without proper componentization, I'll have to do a similar <br>> trick that I did for the HG, ie. make the comms configuration affect the <br>> application classes themselves. But it's a little worse than for the HG, <br>> because the data structures passed around are seriously intertwined <br>> between Environment.Scenes and Comms. As we make improvements in those <br>> data structures (as is the case in the
 ChildAgentUpdate message), we <br>> need to change Environment.Scenes. Plus, regions using OGS1 won't work <br>> with regions using OGS2.<br>> <br>> So the even more real question is this: do we really want to make Comms <br>> a replaceable component? Something that can be completely replaced under <br>> the hood? If so, then componentizing it is a must, and the question is <br>> how. If not, replacing OGS1 with another thing that serves as references <br>> implementation of a standard protocol might be ok.<br>> <br>> Thoughts?<br>> <br>> Crista<br>> <br>> _______________________________________________<br>> Opensim-dev mailing list<br>> Opensim-dev@lists.berlios.de<br>> https://lists.berlios.de/mailman/listinfo/opensim-dev<br>> <br>> <br>_______________________________________________<br>Opensim-dev mailing
 list<br>Opensim-dev@lists.berlios.de<br>https://lists.berlios.de/mailman/listinfo/opensim-dev<br></blockquote><br><p>