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 <[email protected]> >> To: [email protected] >> 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 <[email protected]> >>> To: [email protected] >>> 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 <[email protected]> wrote: >>>> >>>> From: Melanie <[email protected]> >>>> Subject: Re: [Opensim-dev] Deprecate OpenSim.Grid.InventoryServer and >>>> OpenSim.Grid.AssetServer? >>>> To: [email protected] >>>> 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 >>>> [email protected] >>>> https://lists.berlios.de/mailman/listinfo/opensim-dev >>>> >>>> >>>> >>>> >>>> >>>> >>>> ------------------------------------------------------------------------ >>>> >>>> _______________________________________________ >>>> Opensim-dev mailing list >>>> [email protected] >>>> https://lists.berlios.de/mailman/listinfo/opensim-dev >>>> >>> _______________________________________________ >>> Opensim-dev mailing list >>> [email protected] >>> https://lists.berlios.de/mailman/listinfo/opensim-dev >>> >>> >>> >>> ------------------------------------------------------------------------ >>> >>> _______________________________________________ >>> Opensim-dev mailing list >>> [email protected] >>> https://lists.berlios.de/mailman/listinfo/opensim-dev >>> >> _______________________________________________ >> Opensim-dev mailing list >> [email protected] >> https://lists.berlios.de/mailman/listinfo/opensim-dev >> >> >> >> ------------------------------------------------------------------------ >> >> _______________________________________________ >> Opensim-dev mailing list >> [email protected] >> https://lists.berlios.de/mailman/listinfo/opensim-dev >> > _______________________________________________ > Opensim-dev mailing list > [email protected] > https://lists.berlios.de/mailman/listinfo/opensim-dev > >
_______________________________________________ Opensim-dev mailing list [email protected] https://lists.berlios.de/mailman/listinfo/opensim-dev
