Trunk is the developer's working copy, and is guaranteed to veryt likely be broken in one manner or another at any given time. Sometimes a revision is tagged as a release, those are usually tested and will often contain less bugs than any random version in svn.
On Sun, May 17, 2009 at 10:03 PM, <[email protected]> wrote: > I really hope you guys don't do all your work in trunk, not sure what you > policy is but to me only tested code should be in truck which means no one > should be working directly in trunk for anything. > > Also something I wanted to share. I have been sitting in the OpenSim IRC > channel for weeks and looking for some opportunities to help but for me at > least, can't speak for everyone, it is really hard to know what efforts are > going. Is there some kind of release plan or documented branch plan? I > have heard people say they don't like to document and plan but I do think no > documentation or planning makes it hard for others to help. At least for > me. > > Kevin Tweedy > > > > > > -------- Original Message -------- > Subject: Re: [Opensim-dev] WARNING: r9562 may break things > From: [email protected] > Date: Fri, May 15, 2009 9:26 am > To: [email protected] > > 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 > > > _______________________________________________ > 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
