[Opensim-dev] WARNING: r9562 may break things
diva at metaverseink.com
diva at metaverseink.com
Fri May 15 16:26:26 UTC 2009
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, diva at metaverseink.com /<diva at metaverseink.com>/*
> wrote:
>
>
> From: diva at metaverseink.com <diva at metaverseink.com>
> Subject: Re: [Opensim-dev] WARNING: r9562 may break things
> To: opensim-dev at lists.berlios.de
> 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 /<melanie at t-data.com
> </mc/compose?to=melanie at t-data.com>>/* wrote:
> >
> >
> > From: Melanie <melanie at t-data.com
> </mc/compose?to=melanie at t-data.com>>
> > Subject: Re: [Opensim-dev] WARNING: r9562 may break things
> > To: opensim-dev at lists.berlios.de
> </mc/compose?to=opensim-dev at lists.berlios.de>
> > 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, diva at metaverseink.com
> </mc/compose?to=diva at metaverseink.com>
> > </mc/compose?to=diva at metaverseink.com
> </mc/compose?to=diva at metaverseink.com>> <diva at metaverseink.com
> </mc/compose?to=diva at metaverseink.com>
> > </mc/compose?to=diva at metaverseink.com
> </mc/compose?to=diva at metaverseink.com>>> wrote:
> > >
> > > From: diva at metaverseink.com
> </mc/compose?to=diva at metaverseink.com>
> > </mc/compose?to=diva at metaverseink.com
> </mc/compose?to=diva at metaverseink.com>> <diva at metaverseink.com
> </mc/compose?to=diva at metaverseink.com>
> > </mc/compose?to=diva at metaverseink.com
> </mc/compose?to=diva at metaverseink.com>>>
> > > Subject: [Opensim-dev] WARNING: r9562 may break things
> > > To: "opensim-dev at lists.berlios.de
> </mc/compose?to=opensim-dev at lists..berlios.de>
> > </mc/compose?to=opensim-dev at lists.berlios.de
> </mc/compose?to=opensim-dev at lists.berlios.de>>"
> > <opensim-dev at lists.berlios.de
> </mc/compose?to=opensim-dev at lists.berlios.de>
> > </mc/compose?to=opensim-dev at lists.berlios.de
> </mc/compose?to=opensim-dev at lists.berlios.de>>>
> > > 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
> > > Opensim-dev at lists.berlios.de
> </mc/compose?to=Opensim-dev at lists.berlios.de>
> > </mc/compose?to=Opensim-dev at lists.berlios.de
> </mc/compose?to=Opensim-dev at lists.berlios.de>>
> > > https://lists.berlios.de/mailman/listinfo/opensim-dev
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> >
> ------------------------------------------------------------------------
> > >
> > > _______________________________________________
> > > Opensim-dev mailing list
> > > Opensim-dev at lists.berlios.de
> </mc/compose?to=Opensim-dev at lists.berlios.de>
> > </mc/compose?to=Opensim-dev at lists.berlios.de
> </mc/compose?to=Opensim-dev at lists.berlios.de>>
> > > https://lists.berlios.de/mailman/listinfo/opensim-dev
> > _______________________________________________
> > Opensim-dev mailing list
> > Opensim-dev at lists.berlios.de
> </mc/compose?to=Opensim-dev at lists.berlios.de>
> > </mc/compose?to=Opensim-dev at lists.berlios.de
> </mc/compose?to=Opensim-dev at lists.berlios.de>>
> > https://lists.berlios.de/mailman/listinfo/opensim-dev
> >
> >
> >
> >
> ------------------------------------------------------------------------
> >
> > _______________________________________________
> > Opensim-dev mailing list
> > Opensim-dev at lists.berlios.de
> </mc/compose?to=Opensim-dev at lists.berlios.de>
> > https://lists.berlios.de/mailman/listinfo/opensim-dev
> <https://lists.berlios..de/mailman/listinfo/opensim-dev>
> _______________________________________________
> Opensim-dev mailing list
> Opensim-dev at lists.berlios.de
> </mc/compose?to=Opensim-dev at lists.berlios.de>
> https://lists.berlios.de/mailman/listinfo/opensim-dev
>
>
>
> ------------------------------------------------------------------------
>
> _______________________________________________
> Opensim-dev mailing list
> Opensim-dev at lists.berlios.de
> https://lists.berlios.de/mailman/listinfo/opensim-dev
More information about the Opensim-dev
mailing list