[Opensim-dev] Deprecate OpenSim.Grid.InventoryServer and OpenSim.Grid.AssetServer?
Melanie
melanie at t-data.com
Thu Jul 9 01:08:14 UTC 2009
Firstly, the acclaim is for the connector/services architecture. Not
any new protocol. There isn't one yet.
Secondly, this can't be developed on a drawing board. It needs
community testing and input. It needs to grow. Asking for full
documentation ahead of implementation is the same as killing it.
Thirdly, it's not "my plan" in my head. It's actually a
collaboration between myself and Diva that has been going on for
quite some time already.
Why is this being sidetracked into discussing things that haven't
happened, aren't even close to happening?
The question was simple (and sorry for the emphasis, but I think
it's needed):
IS THERE A BASIC UNDERSTANDING AND AGREEMENT ABOUT REMOVING THE OLD
STYLE, MONOLITHIC, SERVERS IF AND WHEN A SUITABLE AND COMPATIBLE
REPLACEMENT IS READY?
That was all I asked for. Nothing more. Nothing less.
Melanie
MW wrote:
> Where are all these remarks of great acclaim? This is the first I've heard about a new protocol being designed without any plan at all.
>
> I'm all for a new protocol but there needs to be a design and peer review. Please stop adding any more work on a new protocol to the trunk until that process can take place. As my vote is -1 (and consider it a veto vote) on just writing it from a plan in your head when no one else knows what that plan is.
>
> --- On Wed, 8/7/09, Melanie <melanie at t-data.com> wrote:
>
> From: Melanie <melanie at t-data.com>
> Subject: Re: [Opensim-dev] Deprecate OpenSim.Grid.InventoryServer and OpenSim.Grid.AssetServer?
> To: opensim-dev at 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 <melanie at t-data.com>
>>>> To: opensim-dev at 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 <melanie at t-data.com>
>>>>> To: opensim-dev at 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 <melanie at t-data.com> wrote:
>>>>>>
>>>>>> From: Melanie <melanie at t-data.com>
>>>>>> Subject: Re: [Opensim-dev] Deprecate OpenSim.Grid.InventoryServer and OpenSim.Grid.AssetServer?
>>>>>> To: opensim-dev at 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 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
>>>>>
>>>> _______________________________________________
>>>> 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
>>>
>>>
>>
>> _______________________________________________
>> 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