[Opensim-dev] Deprecate OpenSim.Grid.InventoryServer and OpenSim.Grid.AssetServer?
MW
michaelwri22 at yahoo.co.uk
Thu Jul 9 09:24:13 UTC 2009
Yes it is common sense but we still have serious problems with how some things are being handled in this project.
--- On Thu, 9/7/09, Impalah <impalah at gmail.com> wrote:
From: Impalah <impalah at gmail.com>
Subject: Re: [Opensim-dev] Deprecate OpenSim.Grid.InventoryServer and OpenSim.Grid.AssetServer?
To: opensim-dev at lists.berlios.de
Date: Thursday, 9 July, 2009, 10:21 AM
You've won the prize of "Common sense guy of the year".
+1 on separating discussions... I'm lost since 7th or 8th message
2009/7/9 Stefan Andersson <lbsa71 at hotmail.com>
This discussion went west pretty fast it seems.
To try to get things on track; this is what I’ve heard said,
and proposed, in roughly this proposed order:
1)
The BUST architecture might or might not change name. *This
is a separate item for discussion*.
2)
The BUST architecture should be documented. This documentation
is allegedly on the way, but should be seen as a work in progress, like always.
3)
After discussing it thru, reviewing documentation, proofing and
accepting BUST, there will be a round of voting on a proposal to retire the old
exes from the core distro. Everything will ideally work the same, just that the
new exes are configured differently, and allows for way better modularization.
4)
The Cable Beach offspring AssetInventoryServer might or might
not move out of core. *This is a separate item for discussion*.
5)
After retiring the old exes, we can start documenting and peer
reviewing ideas for how a new set of protocols (OGS2) could work. *This is a
separate item for discussion*.
6)
Whether this new protocol should be developed in or outside of
trunk is part of that separate discussion.
7)
BUST will allow OGS1 and OGS2 to exist side by side.
8)
OGS1 might or might not be retired. *This is a separate item
for discussion*
I think the vote to retire the exes came somewhat prematurely, jilting
people. Let’s keep these tracks well separated and move along in an
orderly fashion.
Just to put things in perspective, I would estimate bullets 5-8 probably
to be during 2010. Point 8 probably more around early 2011.
/Stefan
From: opensim-dev-bounces at lists.berlios.de
[mailto:opensim-dev-bounces at lists.berlios.de] On Behalf Of MW
Sent: den 9 juli 2009 02:43
To: opensim-dev at lists.berlios.de
Subject: Re: [Opensim-dev] Deprecate OpenSim.Grid.InventoryServer and
OpenSim.Grid.AssetServer?
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
-----Inline Attachment Follows-----
_______________________________________________
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/20090709/b712f246/attachment-0001.html>
More information about the Opensim-dev
mailing list