Well my vote is that the new protocol is documented before it goes into trunk. There is no reason that the protocol can't be designed before it is implemented.
But anyway if its not documented then my vote would be -1 on it going into trunk. Even if it was a optional extra, it would still lead to confusion and disruption among other things. Something as big as a new protocol does need some design rather than just flying into implementing it and seeing how it turns out. So I believe it is either designed and that plan is published on the mailing list/wiki and then after a review, work can start on implementing it or it goes into a branch and then after it is finished, it can be documented and then a review of it is carried out before it is decided if it goes into trunk. --- On Wed, 8/7/09, Melanie <mela...@t-data.com> wrote: From: Melanie <mela...@t-data.com> Subject: Re: [Opensim-dev] Deprecate OpenSim.Grid.InventoryServer and OpenSim.Grid.AssetServer? To: opensim-dev@lists.berlios.de Date: Wednesday, 8 July, 2009, 11:42 PM It doesn't need to be segregated. This can be done in trunk perfectly well. We have had bad experiences with branches and I believe there is a general aversion to them now. There is no need to push this outside of the core scope, especially since it's already well underway. This whole discussion has been totally sidetracked, questioning the project as a whole, a project that has won great acclaim from my fellow core members and was, among others, called "long overdue" and "badly needed". This entire thread came from me trying to ascertain the fundamental willingness to remove the monolithic servers _at some point_. Melanie Gryc Ueusp wrote: > This is what branches are for. > > Melanie wrote: >> This can not be reasonably done on the forge.. >> >> Melanie >> >> Charles Krinke wrote: >> >>> Sounds like a good argument to put this new work on the forge. >>> >>> That way, we can get it wrung out, completed, functional, tested. >>> >>> This seems to me a reasonable and proper way to change the underlying grid >>> servers without having a revolution in mid-air. >>> >>> Charles >>> >>> >>> >>> >>> ________________________________ >>> From: Melanie <mela...@t-data.com> >>> To: opensim-dev@lists.berlios.de >>> Sent: Wednesday, July 8, 2009 2:51:39 PM >>> Subject: Re: [Opensim-dev] Deprecate OpenSim.Grid.InventoryServer and >>> OpenSim.Grid.AssetServer? >>> >>> Which is precisely what is intended. But the old dinosaur servers >>> are in the way. >>> >>> You can rest assured no grids will be harmed in the making of these >>> servers - to paraphrase the movie industry.... >>> >>> Melanie >>> >>> Charles Krinke wrote: >>> >>>> I believe it is pretty important to ensure that we go forwards in a >>>> compatible manner and not backwards. >>>> >>>> Certainly new implementations of servers, executables, protocols and the >>>> like are encouraged, but we also need to make sure that everything >>>> continues to work. >>>> >>>> Perhaps this new work should be on the forge. Perhaps it should be done in >>>> such a way that the users can ultimately determine which server is >>>> appropriate in a similar manner to differing physics implementations. >>>> >>>> But, regardless, I believe that moving forward in a compatible manner and >>>> making sure we dont shoot ourselves in the foot is very important. I would >>>> counsel caution *and* I would counsel some independent testing to make >>>> sure we are moving forward in a predictable manner. >>>> >>>> Charles >>>> >>>> >>>> >>>> >>>> ________________________________ >>>> From: Melanie <mela...@t-data.com> >>>> To: opensim-dev@lists.berlios.de >>>> Sent: Wednesday, July 8, 2009 2:43:17 PM >>>> Subject: Re: [Opensim-dev] Deprecate OpenSim.Grid.InventoryServer and >>>> OpenSim.Grid.AssetServer? >>>> >>>> This is not going to happen on the drawing board. It can't. And also >>>> it would be taking the second step before the first. >>>> >>>> First, the existing protocols are converted to services, as it has >>>> already happened to asset and inventory services. Those can then run >>>> in B.U.S.T. with full compatibility. >>>> >>>> Then the old server needs to go away. At this point one code base >>>> has been replaced with another one without protocol changes. >>>> >>>> This creates a scenario where new protocols can be developed and >>>> tested without breaking things. Here the protocols will evolve as >>>> they are coded. >>>> >>>> Finally, the new protocols will replace the old, after they have >>>> been tested and used in production by early adopters. >>>> >>>> Melanie >>>> >>>> MW wrote: >>>> >>>>> Well as Justin said, there needs to be plans/documents detailing all the >>>>> details of the replacement protocols before the process of replacing them >>>>> is began. >>>>> >>>>> --- On Wed, 8/7/09, Melanie <mela...@t-data.com> wrote: >>>>> >>>>> From: Melanie <mela...@t-data.com> >>>>> Subject: Re: [Opensim-dev] Deprecate OpenSim.Grid.InventoryServer and >>>>> OpenSim.Grid.AssetServer? >>>>> To: opensim-dev@lists.berlios.de >>>>> Date: Wednesday, 8 July, 2009, 9:08 PM >>>>> >>>>> Hi, >>>>> >>>>> Justin Clark-Casey wrote: >>>>> >>>>>> But the real question was about your statement >>>>>> >>>>>> "But changes are planned as we are moving to more sane protocols." >>>>>> >>>>>> source: >>>>>> https://lists.berlios.de/pipermail/opensim-dev/2009-July/006992.html >>>>>> >>>>>> Who is the 'we' in this? What are these protocols? Why are they more >>>>>> sane, etc., etc.? This is an entirely different >>>>>> question to generalizing the OpenSim grid servers. Perhaps they were >>>>>> not meant to be mixed up in this. >>>>>> >>>>> "We" is all of us, the project, for one, and Diva and I as the devs >>>>> driving this change, too. >>>>> >>>>> Today's wire protocols are not sane. There is no point in >>>>> transferring ALL the user's inventory to EVERY region visited, just >>>>> to get the root folder ID, which is the only thing needed from that >>>>> potentially HUGE blob. >>>>> >>>>> Just to mention one known bit of insanity. >>>>> >>>>> Another part that is not sane is the user services. They aren't >>>>> natively equipped to handle the concept of no authentication or HG, >>>>> or user levels, or scopes. They mix in data items that don't belong >>>>> together just because Linden did. >>>>> >>>>> Assets were already made RESTful and so the asset protocol was >>>>> preserved unchanged. >>>>> The grid server protocol is a lean one and changes will be minimal >>>>> (probably just a XMLRPC->REST conversion if they're not REST already) >>>>> >>>>> Presence is totally insane again. It needs to be ripped out and >>>>> redone, now that we know more about real world demands large grids >>>>> place on the servers. >>>>> >>>>> With the modular architecture, that is a simple as snapping in >>>>> another connector. so if your grid uses a new RESTful gridserver >>>>> protocol, you just use the RESTGridConnector rather than the >>>>> XMLLRPCGridConnector. The service providers and consumers stay the same. >>>>> >>>>> The monolithic servers can't cope with that, so they need to go. >>>>> >>>>> Melanie >>>>> _______________________________________________ >>>>> Opensim-dev mailing list >>>>> Opensim-dev@lists.berlios.de >>>>> https://lists.berlios.de/mailman/listinfo/opensim-dev >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> ------------------------------------------------------------------------ >>>>> >>>>> _______________________________________________ >>>>> Opensim-dev mailing list >>>>> Opensim-dev@lists.berlios.de >>>>> https://lists.berlios.de/mailman/listinfo/opensim-dev >>>>> >>>> _______________________________________________ >>>> Opensim-dev mailing list >>>> Opensim-dev@lists.berlios.de >>>> https://lists.berlios.de/mailman/listinfo/opensim-dev >>>> >>>> >>>> >>>> ------------------------------------------------------------------------ >>>> >>>> _______________________________________________ >>>> Opensim-dev mailing list >>>> Opensim-dev@lists.berlios.de >>>> https://lists.berlios.de/mailman/listinfo/opensim-dev >>>> >>> _______________________________________________ >>> Opensim-dev mailing list >>> Opensim-dev@lists.berlios.de >>> https://lists.berlios.de/mailman/listinfo/opensim-dev >>> >>> >>> >>> ------------------------------------------------------------------------ >>> >>> _______________________________________________ >>> Opensim-dev mailing list >>> Opensim-dev@lists.berlios.de >>> https://lists.berlios.de/mailman/listinfo/opensim-dev >>> >> _______________________________________________ >> Opensim-dev mailing list >> Opensim-dev@lists.berlios.de >> https://lists.berlios.de/mailman/listinfo/opensim-dev >> >> > > _______________________________________________ > Opensim-dev mailing list > Opensim-dev@lists.berlios.de > https://lists.berlios.de/mailman/listinfo/opensim-dev > > _______________________________________________ Opensim-dev mailing list Opensim-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/opensim-dev
_______________________________________________ Opensim-dev mailing list Opensim-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/opensim-dev
