<table cellspacing="0" cellpadding="0" border="0" ><tr><td valign="top" style="font: inherit;">The main concern I have is that the whole empty shell for servers and then loading services sounds exactly like myself and mikkopa having been doing in the GenericGridServerConcept branch. The way it works is that there is a single base server that loads plugins, the plugins can be any service. At the moment the plugins/services are the logic from the current user server and grid server. As we were taking it one step at a time and just getting the base architecture. So with the base server you could have it so it could load all the plugins and act as a combined user server and grid server (and any other services in the future) or have separate servers for each as we have now. It also uses ini (nini) to config the servers and plugins. But of course the work isn't finished, but everyone could have worked on it and improved it.<br><br>The reason this was done in a

 branch is because its big changes and I wanted to get it into some working condition before it went into trunk. Also the fact that it hadn't been talked about in enough details to get a agreement on if it should go into trunk.<br><br>Now I'm not saying that work in what we should have in trunk. I'm just saying there is that work going on, and anyone can get involved in it.. And we should be working together to make it into what we want. But instead we have the situation where we have this new idea what sounds a lot like what has been done in the branch but rather all of us work together we have ended up we two concurrent work in progresses. <br><br>I'm completely fine with going with a different architecture to the one in the branch, although it does sound very similar to melanie's idea anyway. But really we should talk about what is wrong with the current work that is going on in that branch. Not just ignore it and start on her own idea without proper

 input. We are a team and we have to work as a team.<br><br>So my problem isn't with the architecture, far from it from what has been described, just the problem is the way its been done. Not enough details of the plan had been published and just ignoring other current work, what just doesn't help with the future of the project if everyone just goes off and does there own thing, even if thats duplication other current work.<br><br>Anyway I think if nothing else this just goes to show there is no point in us doing anything in branches ever again. <br><br>--- On <b>Fri, 15/5/09, diva@metaverseink.com <i><diva@metaverseink.com></i></b> wrote:<br><blockquote style="border-left: 2px solid rgb(16, 16, 255); margin-left: 5px; padding-left: 5px;"><br>From: diva@metaverseink.com <diva@metaverseink.com><br>Subject: Re: [Opensim-dev] WARNING: r9562 may break things<br>To: opensim-dev@lists.berlios.de<br>Date: Friday, 15 May, 2009, 4:55 PM<br><br><div

 class="plainMail">Let me explain in my own words what this new architecture is all about.<br><br>My original intention with this was purely to improve the software <br>architecture, so that we and others can do a lot more variation very <br>easily. (This was not just my intention, we all know that what we have <br>right now is a pain in the neck, and that it has always been a goal to <br>improve it)<br>Melanie thinks that since we're at it, we might as well improve the <br>protocols on the wire and move everything to HTTP/REST. While I agree <br>that's where we should end up, I would do the transition in 2 steps: <br>first step would be to put the new software architecture in place, the <br>second would be to improve the protocols on the wire. And I would keep <br>the old service connectors around. But I have no problems with changing <br>both things at the same time and getting rid of the old service <br>connectors... Anyway, let me explain.<br><br>The

 new architecture that Melanie is putting in place is wonderful! The <br>focus is now radically on *services*, servers being shells that load any <br>combination of those services. Conceptually, a Service is tuple<br><br><IService,<br>  ServiceImplementation,<br>  ServiceConnectorOut,<br>  ServiceConnectorIn><br><br>Callers of a service know only of IService; that IService on the client <br>side is mapped to a ServiceConnectorOut at initialization time according <br>to the configurations. ServiceConnectorOut encapsulates all the code <br>required to interact with a particular service implementation. So if <br>anyone comes and decides to write a completely new protocol for a <br>service, as long as that protocol can comply with IService this is as <br>easy as that service implementer providing a different <br>ServiceConnectorOut -- no changes on the client side whatsoever.<br><br>The new architecture improves the server-side too. For

 starters, these <br>new servers are configured in exactly the same way as the simulators, <br>with a XXXService.ini. This is already a major improvement for making <br>all our servers consistent -- simulators and UGAIMXX are servers of <br>about the same kind.<br><br>Second, combining services in server shells is now also very easy. For <br>example, the new inventory server can easily be configured to also serve <br>assets, or to interact with a remote asset server. This particular <br>combination basically generates the mix in Cable Beach's <br>AssetInventoryServer, but without having to make it be a big deal.<br>Similarly, it will be very easy to write a server that serves all of <br>UGAIM services, if anyone likes that particular combination. Etc. I <br>think the intention is that OpenSim will continue to provide the 6 <br>servers we have now, but people can now change that very easily.<br><br>Stefan asked "shouldn't the Region server move into the

 Servers as <br>well?" and this is a great question. It probably should, but since the <br>simulator is our big-ass server, I think it's ok if we treat it in a <br>special way. In any case, I started a dll called OpenSim.Simulator whose <br>purpose is to have a set of services that may be enabled on the <br>Simulator server itself. Specifically, this will hold UGAIM <br>ServiceConnectorIn's for standalone grids that let the users go out.<br><br>Does this make sense?<br><br><br>MW wrote:<br>> So can we have some idea of what is being done for the new grid servers, <br>> all the talk I saw was about region side dlls /config setting etc.<br>> <br>> I was already in the middle of making a generic base for grid servers <br>> and modules. I don't care about the actual logic but I would like to see <br>> how we can use the same or similar module system.<br>> <br>> BTW when talking about the servers, I mean the user, grid and messaging

 <br>> servers. I haven't done anything on the asset or inventory side.<br>> <br>> --- On *Fri, 15/5/09, Melanie /<<a ymailto="mailto:melanie@t-data.com" href="/mc/compose?to=melanie@t-data.com">melanie@t-data.com</a>>/* wrote:<br>> <br>> <br>>     From: Melanie <<a ymailto="mailto:melanie@t-data.com" href="/mc/compose?to=melanie@t-data.com">melanie@t-data.com</a>><br>>     Subject: Re: [Opensim-dev] WARNING: r9562 may break things<br>>     To: <a ymailto="mailto:opensim-dev@lists.berlios.de" href="/mc/compose?to=opensim-dev@lists.berlios.de">opensim-dev@lists.berlios.de</a><br>>     Date: Friday, 15 May, 2009, 1:57 PM<br>> <br>>     The old grid servers will be completely replaced. ANything thet is<br>>     getting fixed there will be taken into the new servers, but there is<br>> 

    really no point in architectural work on the old servers..<br>> <br>>     Melanie<br>> <br>>     MW wrote:<br>>      > This is just the region side stuff that is changing? Just<br>>     wondering if anything will conflict with the generic grid server<br>>     work in the branch.<br>>      ><br>>      > Alos on a side note, it would be good if we could tag a new<br>>     stable release from before these changes. >From what feedback I have<br>>     seen, it seems that a revision somewhere around 9395 was about the<br>>     most recent quite stable revision. If there is agreement on that or<br>>     another revision then I'll tag/branch it as a 0.6.5RC.<br>>     

 ><br>>      > --- On Fri, 15/5/09, <a ymailto="mailto:diva@metaverseink.com" href="/mc/compose?to=diva@metaverseink.com">diva@metaverseink.com</a><br>>     </mc/compose?to=<a ymailto="mailto:diva@metaverseink.com" href="/mc/compose?to=diva@metaverseink.com">diva@metaverseink.com</a>> <<a ymailto="mailto:diva@metaverseink.com" href="/mc/compose?to=diva@metaverseink.com">diva@metaverseink.com</a><br>>     </mc/compose?to=<a ymailto="mailto:diva@metaverseink.com" href="/mc/compose?to=diva@metaverseink.com">diva@metaverseink.com</a>>> wrote:<br>>      ><br>>      > From: <a ymailto="mailto:diva@metaverseink.com" href="/mc/compose?to=diva@metaverseink.com">diva@metaverseink.com</a><br>>     </mc/compose?to=<a ymailto="mailto:diva@metaverseink.com"

 href="/mc/compose?to=diva@metaverseink.com">diva@metaverseink.com</a>> <<a ymailto="mailto:diva@metaverseink.com" href="/mc/compose?to=diva@metaverseink.com">diva@metaverseink.com</a><br>>     </mc/compose?to=<a ymailto="mailto:diva@metaverseink.com" href="/mc/compose?to=diva@metaverseink.com">diva@metaverseink.com</a>>><br>>      > Subject: [Opensim-dev] WARNING: r9562 may break things<br>>      > To: "<a ymailto="mailto:opensim-dev@lists.berlios.de" href="/mc/compose?to=opensim-dev@lists..berlios.de">opensim-dev@lists.berlios.de</a><br>>     </mc/compose?to=<a ymailto="mailto:opensim-dev@lists.berlios.de" href="/mc/compose?to=opensim-dev@lists.berlios.de">opensim-dev@lists.berlios.de</a>>"<br>>     <<a ymailto="mailto:opensim-dev@lists.berlios.de"

href="/mc/compose?to=opensim-dev@lists.berlios.de">opensim-dev@lists.berlios.de</a> >     </mc/compose?to=<a ymailto="mailto:opensim-dev@lists.berlios.de" href="/mc/compose?to=opensim-dev@lists.berlios.de">opensim-dev@lists.berlios.de</a>>> >      > Date: Friday, 15 May, 2009, 6:23 AM >      > >      > Everyone -- >      > Just a warning to please stay away from head, starting in r9562, >     for the >      > next couple of days unless you really really really want to help >     test >      > things. We started replacing the services to the new service >     model that >      > was discussed here a few weeks ago, staring with the asset >     service.

 For<br>>      > starters, there are new configuration variables in OpenSim.ini<br>>     that you<br>>      > need to get acquainted with -- see the OpenSim.ini..example at the<br>>      > bottom. But unless you really need to be in head, don't; please<br>>     wait at<br>>      > least 24 hours.<br>>      ><br>>      > Melanie --<br>>      > The transplant is mostly done. See commit message for the things<br>>     that<br>>      > are borked. Also note, I changed the config var you had called<br>>     "Modules"<br>>      > to "ServiceConnectors", you probably need to change your local .ini.<br>>      > Talk to you tomorrow.<br>>      >

 _______________________________________________<br>>      > Opensim-dev mailing list<br>>      > <a ymailto="mailto:Opensim-dev@lists.berlios.de" href="/mc/compose?to=Opensim-dev@lists.berlios.de">Opensim-dev@lists.berlios.de</a><br>>     </mc/compose?to=<a ymailto="mailto:Opensim-dev@lists.berlios.de" href="/mc/compose?to=Opensim-dev@lists.berlios.de">Opensim-dev@lists.berlios.de</a>><br>>      > <a href="https://lists.berlios.de/mailman/listinfo/opensim-dev" target="_blank">https://lists.berlios.de/mailman/listinfo/opensim-dev</a><br>>      ><br>>      ><br>>      ><br>>      >       <br>>      ><br>>      ><br>>      ><br>> 

    ------------------------------------------------------------------------<br>>      ><br>>      > _______________________________________________<br>>      > Opensim-dev mailing list<br>>      > <a ymailto="mailto:Opensim-dev@lists.berlios.de" href="/mc/compose?to=Opensim-dev@lists.berlios.de">Opensim-dev@lists.berlios.de</a><br>>     </mc/compose?to=<a ymailto="mailto:Opensim-dev@lists.berlios.de" href="/mc/compose?to=Opensim-dev@lists.berlios.de">Opensim-dev@lists.berlios.de</a>><br>>      > <a href="https://lists.berlios.de/mailman/listinfo/opensim-dev" target="_blank">https://lists.berlios.de/mailman/listinfo/opensim-dev</a><br>>     _______________________________________________<br>>     Opensim-dev mailing list<br>>     <a

 ymailto="mailto:Opensim-dev@lists.berlios.de" href="/mc/compose?to=Opensim-dev@lists.berlios.de">Opensim-dev@lists.berlios.de</a><br>>     </mc/compose?to=<a ymailto="mailto:Opensim-dev@lists.berlios.de" href="/mc/compose?to=Opensim-dev@lists.berlios.de">Opensim-dev@lists.berlios.de</a>><br>>     <a href="https://lists.berlios.de/mailman/listinfo/opensim-dev" target="_blank">https://lists.berlios.de/mailman/listinfo/opensim-dev</a><br>> <br>> <br>> <br>> ------------------------------------------------------------------------<br>> <br>> _______________________________________________<br>> Opensim-dev mailing list<br>> <a ymailto="mailto:Opensim-dev@lists.berlios.de" href="/mc/compose?to=Opensim-dev@lists.berlios.de">Opensim-dev@lists.berlios.de</a><br>> <a href="https://lists.berlios..de/mailman/listinfo/opensim-dev"

 target="_blank">https://lists.berlios.de/mailman/listinfo/opensim-dev</a><br>_______________________________________________<br>Opensim-dev mailing list<br><a ymailto="mailto:Opensim-dev@lists.berlios.de" href="/mc/compose?to=Opensim-dev@lists.berlios.de">Opensim-dev@lists.berlios.de</a><br><a href="https://lists.berlios.de/mailman/listinfo/opensim-dev" target="_blank">https://lists.berlios.de/mailman/listinfo/opensim-dev</a><br></div></blockquote></td></tr></table><br>