[Opensim-dev] WARNING: r9562 may break things
MW
michaelwri22 at yahoo.co.uk
Fri May 15 16:20:20 UTC 2009
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>/* wrote:
>
>
> From: Melanie <melanie at t-data.com>
> Subject: Re: [Opensim-dev] WARNING: r9562 may break things
> 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> <diva at metaverseink.com
> </mc/compose?to=diva at metaverseink.com>> wrote:
> >
> > From: diva at metaverseink.com
> </mc/compose?to=diva at metaverseink.com> <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>"
> <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>
> > 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
> </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
_______________________________________________
Opensim-dev mailing list
Opensim-dev at lists.berlios.de
https://lists.berlios.de/mailman/listinfo/opensim-dev
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://opensimulator.org/pipermail/opensim-dev/attachments/20090515/eb081dca/attachment-0001.html>
More information about the Opensim-dev
mailing list