[Opensim-dev] WARNING: r9562 may break things

Arthur Valadares arthursv at linux.vnet.ibm.com
Mon May 18 18:44:21 UTC 2009


As for your other question, we have all kinds of fronts going on at the
same time. When we have major changes coming, we will always warn and
ask for input on the opensim-dev mailing list. Other then that, feel
free to contribute wherever you wish. If it's not such a big thing,
unless you're very unlucky to start at the same time as someone else,
you shouldn't conflict. If it's a big thing and not announced on -dev
channel, also feel free to start on it and do publicize it on the
channel so no one wastes work :)

We don't have any very longs plans, it's more of a fast find and develop
programming scheme.

If you don't know where to start, Mantis is always good for showing you
common places of issues that we could use help in. Also, by fixing bugs
you also see things that could be made faster or more clean. 

And if none of that helps, feel free to ping other developers and ask
what they're doing, we (some of us) don't bite ;)

On Sun, 2009-05-17 at 22:03 -0700, 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




More information about the Opensim-dev mailing list