[Opensim-dev] WARNING: r9562 may break things

Mon May 18 05:15:02 UTC 2009

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, <mysticaldemina at xrgrid.com> 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: diva at metaverseink.com
> Date: Fri, May 15, 2009 9:26 am
> To: opensim-dev at lists.berlios.de
>
> 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
> _______________________________________________
> 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/20090517/72b6b884/attachment-0001.html>