I had no idea there was a separate branch about this! We should definitely work together on this, rather than separate. Talking about lack of communication... :D
MW wrote: > 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. > > 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. > > 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. > > 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. > > 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. > > Anyway I think if nothing else this just goes to show there is no point > in us doing anything in branches ever again. > > --- On *Fri, 15/5/09, [email protected] /<[email protected]>/* > wrote: > > > From: [email protected] <[email protected]> > Subject: Re: [Opensim-dev] WARNING: r9562 may break things > To: [email protected] > Date: Friday, 15 May, 2009, 4:55 PM > > Let me explain in my own words what this new architecture is all about. > > My original intention with this was purely to improve the software > architecture, so that we and others can do a lot more variation very > easily. (This was not just my intention, we all know that what we have > right now is a pain in the neck, and that it has always been a goal to > improve it) > Melanie thinks that since we're at it, we might as well improve the > protocols on the wire and move everything to HTTP/REST. While I agree > that's where we should end up, I would do the transition in 2 steps: > first step would be to put the new software architecture in place, the > second would be to improve the protocols on the wire. And I would keep > the old service connectors around. But I have no problems with changing > both things at the same time and getting rid of the old service > connectors... Anyway, let me explain. > > The new architecture that Melanie is putting in place is wonderful! The > focus is now radically on *services*, servers being shells that load > any > combination of those services. Conceptually, a Service is tuple > > <IService, > ServiceImplementation, > ServiceConnectorOut, > ServiceConnectorIn> > > Callers of a service know only of IService; that IService on the client > side is mapped to a ServiceConnectorOut at initialization time > according > to the configurations. ServiceConnectorOut encapsulates all the code > required to interact with a particular service implementation. So if > anyone comes and decides to write a completely new protocol for a > service, as long as that protocol can comply with IService this is as > easy as that service implementer providing a different > ServiceConnectorOut -- no changes on the client side whatsoever. > > The new architecture improves the server-side too. For starters, these > new servers are configured in exactly the same way as the simulators, > with a XXXService.ini. This is already a major improvement for making > all our servers consistent -- simulators and UGAIMXX are servers of > about the same kind. > > Second, combining services in server shells is now also very easy. For > example, the new inventory server can easily be configured to also > serve > assets, or to interact with a remote asset server. This particular > combination basically generates the mix in Cable Beach's > AssetInventoryServer, but without having to make it be a big deal. > Similarly, it will be very easy to write a server that serves all of > UGAIM services, if anyone likes that particular combination. Etc. I > think the intention is that OpenSim will continue to provide the 6 > servers we have now, but people can now change that very easily. > > Stefan asked "shouldn't the Region server move into the Servers as > well?" and this is a great question. It probably should, but since the > simulator is our big-ass server, I think it's ok if we treat it in a > special way. In any case, I started a dll called OpenSim.Simulator > whose > purpose is to have a set of services that may be enabled on the > Simulator server itself. Specifically, this will hold UGAIM > ServiceConnectorIn's for standalone grids that let the users go out. > > Does this make sense? > > > MW wrote: > > So can we have some idea of what is being done for the new grid > servers, > > all the talk I saw was about region side dlls /config setting etc. > > > > I was already in the middle of making a generic base for grid > servers > > and modules. I don't care about the actual logic but I would like > to see > > how we can use the same or similar module system. > > > > BTW when talking about the servers, I mean the user, grid and > messaging > > servers. I haven't done anything on the asset or inventory side. > > > > --- On *Fri, 15/5/09, Melanie /<[email protected] > </mc/[email protected]>>/* wrote: > > > > > > From: Melanie <[email protected] > </mc/[email protected]>> > > Subject: Re: [Opensim-dev] WARNING: r9562 may break things > > To: [email protected] > </mc/[email protected]> > > Date: Friday, 15 May, 2009, 1:57 PM > > > > The old grid servers will be completely replaced. ANything > thet is > > getting fixed there will be taken into the new servers, but > there is > > really no point in architectural work on the old servers.. > > > > Melanie > > > > MW wrote: > > > This is just the region side stuff that is changing? Just > > wondering if anything will conflict with the generic grid server > > work in the branch. > > > > > > Alos on a side note, it would be good if we could tag a new > > stable release from before these changes. >From what feedback > I have > > seen, it seems that a revision somewhere around 9395 was > about the > > most recent quite stable revision. If there is agreement on > that or > > another revision then I'll tag/branch it as a 0.6.5RC. > > > > > > --- On Fri, 15/5/09, [email protected] > </mc/[email protected]> > > </mc/[email protected] > </mc/[email protected]>> <[email protected] > </mc/[email protected]> > > </mc/[email protected] > </mc/[email protected]>>> wrote: > > > > > > From: [email protected] > </mc/[email protected]> > > </mc/[email protected] > </mc/[email protected]>> <[email protected] > </mc/[email protected]> > > </mc/[email protected] > </mc/[email protected]>>> > > > Subject: [Opensim-dev] WARNING: r9562 may break things > > > To: "[email protected] > </mc/[email protected]> > > </mc/[email protected] > </mc/[email protected]>>" > > <[email protected] > </mc/[email protected]> > > </mc/[email protected] > </mc/[email protected]>>> > > > 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 > > > starters, there are new configuration variables in OpenSim.ini > > that you > > > need to get acquainted with -- see the > OpenSim.ini..example at the > > > bottom. But unless you really need to be in head, don't; > please > > wait at > > > least 24 hours. > > > > > > Melanie -- > > > The transplant is mostly done. See commit message for the > things > > that > > > are borked. Also note, I changed the config var you had called > > "Modules" > > > to "ServiceConnectors", you probably need to change your > local .ini. > > > Talk to you tomorrow. > > > _______________________________________________ > > > Opensim-dev mailing list > > > [email protected] > </mc/[email protected]> > > </mc/[email protected] > </mc/[email protected]>> > > > https://lists.berlios.de/mailman/listinfo/opensim-dev > > > > > > > > > > > > > > > > > > > > > > > > > ------------------------------------------------------------------------ > > > > > > _______________________________________________ > > > Opensim-dev mailing list > > > [email protected] > </mc/[email protected]> > > </mc/[email protected] > </mc/[email protected]>> > > > https://lists.berlios.de/mailman/listinfo/opensim-dev > > _______________________________________________ > > Opensim-dev mailing list > > [email protected] > </mc/[email protected]> > > </mc/[email protected] > </mc/[email protected]>> > > https://lists.berlios.de/mailman/listinfo/opensim-dev > > > > > > > > > ------------------------------------------------------------------------ > > > > _______________________________________________ > > Opensim-dev mailing list > > [email protected] > </mc/[email protected]> > > https://lists.berlios.de/mailman/listinfo/opensim-dev > <https://lists.berlios..de/mailman/listinfo/opensim-dev> > _______________________________________________ > Opensim-dev mailing list > [email protected] > </mc/[email protected]> > https://lists.berlios.de/mailman/listinfo/opensim-dev > > > > ------------------------------------------------------------------------ > > _______________________________________________ > Opensim-dev mailing list > [email protected] > https://lists.berlios.de/mailman/listinfo/opensim-dev _______________________________________________ Opensim-dev mailing list [email protected] https://lists.berlios.de/mailman/listinfo/opensim-dev
