You've won the prize of "Common sense guy of the year".<br><br>+1 on separating discussions... I'm lost since 7th or 8th message<br><br><br><div class="gmail_quote">2009/7/9 Stefan Andersson <span dir="ltr"><<a href="mailto:lbsa71@hotmail.com">lbsa71@hotmail.com</a>></span><br>
<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<div link="blue" vlink="purple" lang="EN-US">
<div>
<p><span style="font-size: 11pt; color: rgb(31, 73, 125);">This discussion went west pretty fast it seems.</span></p>
<p><span style="font-size: 11pt; color: rgb(31, 73, 125);"> </span></p>
<p><span style="font-size: 11pt; color: rgb(31, 73, 125);">To try to get things on track; this is what I’ve heard said,
and proposed, in roughly this proposed order:</span></p>
<p><span style="font-size: 11pt; color: rgb(31, 73, 125);"> </span></p>
<p style="text-indent: -0.25in;"><span style="font-size: 11pt; color: rgb(31, 73, 125);"><span>1)<span style="font-family: "Times New Roman"; font-style: normal; font-variant: normal; font-weight: normal; font-size: 7pt; line-height: normal; font-size-adjust: none; font-stretch: normal;">
</span></span></span><span style="font-size: 11pt; color: rgb(31, 73, 125);">The BUST architecture might or might not change name. *<b>This
is a separate item for discussion</b>*.</span></p>
<p style="text-indent: -0.25in;"><span style="font-size: 11pt; color: rgb(31, 73, 125);"><span>2)<span style="font-family: "Times New Roman"; font-style: normal; font-variant: normal; font-weight: normal; font-size: 7pt; line-height: normal; font-size-adjust: none; font-stretch: normal;">
</span></span></span><span style="font-size: 11pt; color: rgb(31, 73, 125);">The BUST architecture should be documented. This documentation
is allegedly on the way, but should be seen as a work in progress, like always.</span></p>
<p style="text-indent: -0.25in;"><span style="font-size: 11pt; color: rgb(31, 73, 125);"><span>3)<span style="font-family: "Times New Roman"; font-style: normal; font-variant: normal; font-weight: normal; font-size: 7pt; line-height: normal; font-size-adjust: none; font-stretch: normal;">
</span></span></span><span style="font-size: 11pt; color: rgb(31, 73, 125);">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.</span></p>
<p style="text-indent: -0.25in;"><span style="font-size: 11pt; color: rgb(31, 73, 125);"><span>4)<span style="font-family: "Times New Roman"; font-style: normal; font-variant: normal; font-weight: normal; font-size: 7pt; line-height: normal; font-size-adjust: none; font-stretch: normal;">
</span></span></span><span style="font-size: 11pt; color: rgb(31, 73, 125);">The Cable Beach offspring AssetInventoryServer might or might
not move out of core. *<b>This is a separate item for discussion</b>*.</span></p>
<p style="text-indent: -0.25in;"><span style="font-size: 11pt; color: rgb(31, 73, 125);"><span>5)<span style="font-family: "Times New Roman"; font-style: normal; font-variant: normal; font-weight: normal; font-size: 7pt; line-height: normal; font-size-adjust: none; font-stretch: normal;">
</span></span></span><span style="font-size: 11pt; color: rgb(31, 73, 125);">After retiring the old exes, we can start documenting and peer
reviewing ideas for how a new set of protocols (OGS2) could work. *<b>This is a
separate item for discussion</b>*. </span></p>
<p style="text-indent: -0.25in;"><span style="font-size: 11pt; color: rgb(31, 73, 125);"><span>6)<span style="font-family: "Times New Roman"; font-style: normal; font-variant: normal; font-weight: normal; font-size: 7pt; line-height: normal; font-size-adjust: none; font-stretch: normal;">
</span></span></span><span style="font-size: 11pt; color: rgb(31, 73, 125);">Whether this new protocol should be developed in or outside of
trunk is part of that separate discussion.</span></p>
<p style="text-indent: -0.25in;"><span style="font-size: 11pt; color: rgb(31, 73, 125);"><span>7)<span style="font-family: "Times New Roman"; font-style: normal; font-variant: normal; font-weight: normal; font-size: 7pt; line-height: normal; font-size-adjust: none; font-stretch: normal;">
</span></span></span><span style="font-size: 11pt; color: rgb(31, 73, 125);">BUST will allow OGS1 and OGS2 to exist side by side.</span></p>
<p style="text-indent: -0.25in;"><span style="font-size: 11pt; color: rgb(31, 73, 125);"><span>8)<span style="font-family: "Times New Roman"; font-style: normal; font-variant: normal; font-weight: normal; font-size: 7pt; line-height: normal; font-size-adjust: none; font-stretch: normal;">
</span></span></span><span style="font-size: 11pt; color: rgb(31, 73, 125);">OGS1 might or might not be retired. *<b>This is a separate item
for discussion</b>*</span></p>
<p><span style="font-size: 11pt; color: rgb(31, 73, 125);"> </span></p>
<p><span style="font-size: 11pt; color: rgb(31, 73, 125);">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.</span></p>
<p><span style="font-size: 11pt; color: rgb(31, 73, 125);"> </span></p>
<p><span style="font-size: 11pt; color: rgb(31, 73, 125);">Just to put things in perspective, I would estimate bullets 5-8 probably
to be during 2010. Point 8 probably more around early 2011.</span></p>
<p><span style="font-size: 11pt; color: rgb(31, 73, 125);"> </span></p>
<p><span style="font-size: 11pt; color: rgb(31, 73, 125);">/Stefan</span></p>
<p><span style="font-size: 11pt; color: rgb(31, 73, 125);"> </span></p>
<div style="border-style: none none none solid; border-color: -moz-use-text-color -moz-use-text-color -moz-use-text-color blue; border-width: medium medium medium 1.5pt; padding: 0in 0in 0in 4pt;">
<div>
<div style="border-style: solid none none; border-color: rgb(181, 196, 223) -moz-use-text-color -moz-use-text-color; border-width: 1pt medium medium; padding: 3pt 0in 0in;">
<p><b><span style="font-size: 10pt;">From:</span></b><span style="font-size: 10pt;"> <a href="mailto:opensim-dev-bounces@lists.berlios.de" target="_blank">opensim-dev-bounces@lists.berlios.de</a>
[mailto:<a href="mailto:opensim-dev-bounces@lists.berlios.de" target="_blank">opensim-dev-bounces@lists.berlios.de</a>] <b>On Behalf Of </b>MW<br>
<b>Sent:</b> den 9 juli 2009 02:43<div><div></div><div class="h5"><br>
<b>To:</b> <a href="mailto:opensim-dev@lists.berlios.de" target="_blank">opensim-dev@lists.berlios.de</a><br>
<b>Subject:</b> Re: [Opensim-dev] Deprecate OpenSim.Grid.InventoryServer and
OpenSim.Grid.AssetServer?</div></div></span></p>
</div>
</div><div><div></div><div class="h5">
<p> </p>
<table border="0" cellpadding="0" cellspacing="0">
<tbody><tr>
<td style="padding: 0in;" valign="top">
<p>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.
<br>
<br>
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. <br>
<br>
--- On <b>Wed, 8/7/09, Melanie <i><<a href="mailto:melanie@t-data.com" target="_blank">melanie@t-data.com</a>></i></b> wrote:</p>
<p style="margin-bottom: 12pt;"><br>
From: Melanie <<a href="mailto:melanie@t-data.com" target="_blank">melanie@t-data.com</a>><br>
Subject: Re: [Opensim-dev] Deprecate OpenSim.Grid.InventoryServer and
OpenSim.Grid.AssetServer?<br>
To: <a href="mailto:opensim-dev@lists.berlios.de" target="_blank">opensim-dev@lists.berlios.de</a><br>
Date: Wednesday, 8 July, 2009, 11:42 PM</p>
<div>
<p>It doesn't need to be segregated. This can be done in
trunk <br>
perfectly well. We have had bad experiences with branches and I <br>
believe there is a general aversion to them now.<br>
<br>
There is no need to push this outside of the core scope, especially <br>
since it's already well underway. This whole discussion has been <br>
totally sidetracked, questioning the project as a whole, a project <br>
that has won great acclaim from my fellow core members and was, <br>
among others, called "long overdue" and "badly needed".<br>
<br>
This entire thread came from me trying to ascertain the fundamental <br>
willingness to remove the monolithic servers _at some point_.<br>
<br>
Melanie<br>
<br>
<br>
Gryc Ueusp wrote:<br>
> This is what branches are for.<br>
> <br>
> Melanie wrote:<br>
>> This can not be reasonably done on the forge..<br>
>><br>
>> Melanie<br>
>><br>
>> Charles Krinke wrote:<br>
>> <br>
>>> Sounds like a good argument to put this new work on the forge.<br>
>>><br>
>>> That way, we can get it wrung out, completed, functional,
tested. <br>
>>><br>
>>> This seems to me a reasonable and proper way to change the
underlying grid servers without having a revolution in mid-air.<br>
>>><br>
>>> Charles<br>
>>><br>
>>><br>
>>><br>
>>><br>
>>> ________________________________<br>
>>> From: Melanie <<a href="http://mc/compose?to=melanie@t-data.com" target="_blank">melanie@t-data.com</a>><br>
>>> To: <a href="http://mc/compose?to=opensim-dev@lists.berlios.de" target="_blank">opensim-dev@lists.berlios.de</a><br>
>>> Sent: Wednesday, July 8, 2009 2:51:39 PM<br>
>>> Subject: Re: [Opensim-dev] Deprecate
OpenSim.Grid.InventoryServer and OpenSim.Grid.AssetServer?<br>
>>><br>
>>> Which is precisely what is intended. But the old dinosaur
servers <br>
>>> are in the way.<br>
>>><br>
>>> You can rest assured no grids will be harmed in the making of
these <br>
>>> servers - to paraphrase the movie industry....<br>
>>><br>
>>> Melanie<br>
>>><br>
>>> Charles Krinke wrote:<br>
>>> <br>
>>>> I believe it is pretty important to ensure that we go
forwards in a compatible manner and not backwards.<br>
>>>><br>
>>>> Certainly new implementations of servers, executables,
protocols and the like are encouraged, but we also need to make sure that
everything continues to work.<br>
>>>><br>
>>>> 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.<br>
>>>><br>
>>>> 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.<br>
>>>><br>
>>>> Charles<br>
>>>><br>
>>>><br>
>>>><br>
>>>><br>
>>>> ________________________________<br>
>>>> From: Melanie <<a href="http://mc/compose?to=melanie@t-data.com" target="_blank">melanie@t-data.com</a>><br>
>>>> To: <a href="http://mc/compose?to=opensim-dev@lists.berlios.de" target="_blank">opensim-dev@lists.berlios.de</a><br>
>>>> Sent: Wednesday, July 8, 2009 2:43:17 PM<br>
>>>> Subject: Re: [Opensim-dev] Deprecate
OpenSim.Grid.InventoryServer and OpenSim.Grid.AssetServer?<br>
>>>><br>
>>>> This is not going to happen on the drawing board. It can't.
And also <br>
>>>> it would be taking the second step before the first.<br>
>>>><br>
>>>> First, the existing protocols are converted to services, as
it has <br>
>>>> already happened to asset and inventory services. Those can
then run <br>
>>>> in B.U.S.T. with full compatibility.<br>
>>>><br>
>>>> Then the old server needs to go away. At this point one code
base <br>
>>>> has been replaced with another one without protocol changes.<br>
>>>><br>
>>>> This creates a scenario where new protocols can be developed
and <br>
>>>> tested without breaking things. Here the protocols will
evolve as <br>
>>>> they are coded.<br>
>>>><br>
>>>> Finally, the new protocols will replace the old, after they
have <br>
>>>> been tested and used in production by early adopters.<br>
>>>><br>
>>>> Melanie<br>
>>>><br>
>>>> MW wrote:<br>
>>>> <br>
>>>>> 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.<br>
>>>>><br>
>>>>> --- On Wed, 8/7/09, Melanie <<a href="http://mc/compose?to=melanie@t-data.com" target="_blank">melanie@t-data.com</a>> wrote:<br>
>>>>><br>
>>>>> From: Melanie <<a href="http://mc/compose?to=melanie@t-data.com" target="_blank">melanie@t-data.com</a>><br>
>>>>> Subject: Re: [Opensim-dev] Deprecate
OpenSim.Grid.InventoryServer and OpenSim.Grid.AssetServer?<br>
>>>>> To: <a href="http://mc/compose?to=opensim-dev@lists.berlios.de" target="_blank">opensim-dev@lists.berlios.de</a><br>
>>>>> Date: Wednesday, 8 July, 2009, 9:08 PM<br>
>>>>><br>
>>>>> Hi,<br>
>>>>><br>
>>>>> Justin Clark-Casey wrote:<br>
>>>>> <br>
>>>>>> But the real question was about your statement<br>
>>>>>><br>
>>>>>> "But changes are planned as we are moving to
more sane protocols."<br>
>>>>>><br>
>>>>>> source: <a href="https://lists.berlios.de/pipermail/opensim-dev/2009-July/006992.html" target="_blank">https://lists.berlios.de/pipermail/opensim-dev/2009-July/006992.html</a><br>
>>>>>><br>
>>>>>> Who is the 'we' in this? What are these
protocols? Why are they more sane, etc., etc.? This is an
entirely different <br>
>>>>>> question to generalizing the OpenSim grid
servers. Perhaps they were not meant to be mixed up in this.<br>
>>>>>> <br>
>>>>> "We" is all of us, the project, for one, and
Diva and I as the devs <br>
>>>>> driving this change, too.<br>
>>>>><br>
>>>>> Today's wire protocols are not sane. There is no point
in <br>
>>>>> transferring ALL the user's inventory to EVERY region
visited, just <br>
>>>>> to get the root folder ID, which is the only thing
needed from that <br>
>>>>> potentially HUGE blob.<br>
>>>>><br>
>>>>> Just to mention one known bit of insanity.<br>
>>>>><br>
>>>>> Another part that is not sane is the user services. They
aren't <br>
>>>>> natively equipped to handle the concept of no
authentication or HG, <br>
>>>>> or user levels, or scopes. They mix in data items that
don't belong <br>
>>>>> together just because Linden did.<br>
>>>>><br>
>>>>> Assets were already made RESTful and so the asset
protocol was <br>
>>>>> preserved unchanged.<br>
>>>>> The grid server protocol is a lean one and changes will
be minimal <br>
>>>>> (probably just a XMLRPC->REST conversion if they're
not REST already)<br>
>>>>><br>
>>>>> Presence is totally insane again. It needs to be ripped
out and <br>
>>>>> redone, now that we know more about real world demands
large grids <br>
>>>>> place on the servers.<br>
>>>>><br>
>>>>> With the modular architecture, that is a simple as
snapping in <br>
>>>>> another connector. so if your grid uses a new RESTful
gridserver <br>
>>>>> protocol, you just use the RESTGridConnector rather than
the <br>
>>>>> XMLLRPCGridConnector. The service providers and
consumers stay the same.<br>
>>>>><br>
>>>>> The monolithic servers can't cope with that, so they
need to go.<br>
>>>>><br>
>>>>> Melanie<br>
>>>>> _______________________________________________<br>
>>>>> Opensim-dev mailing list<br>
>>>>> <a href="http://mc/compose?to=Opensim-dev@lists.berlios.de" target="_blank">Opensim-dev@lists.berlios.de</a><br>
>>>>> <a href="https://lists.berlios.de/mailman/listinfo/opensim-dev" target="_blank">https://lists.berlios.de/mailman/listinfo/opensim-dev</a><br>
>>>>><br>
>>>>><br>
>>>>><br>
>>>>> <br>
>>>>><br>
>>>>><br>
>>>>>
------------------------------------------------------------------------<br>
>>>>><br>
>>>>> _______________________________________________<br>
>>>>> Opensim-dev mailing list<br>
>>>>> <a href="http://mc/compose?to=Opensim-dev@lists.berlios.de" target="_blank">Opensim-dev@lists.berlios.de</a><br>
>>>>> <a href="https://lists.berlios.de/mailman/listinfo/opensim-dev" target="_blank">https://lists.berlios.de/mailman/listinfo/opensim-dev</a><br>
>>>>> <br>
>>>> _______________________________________________<br>
>>>> Opensim-dev mailing list<br>
>>>> <a href="http://mc/compose?to=Opensim-dev@lists.berlios.de" target="_blank">Opensim-dev@lists.berlios.de</a><br>
>>>> <a href="https://lists.berlios..de/mailman/listinfo/opensim-dev" target="_blank">https://lists.berlios.de/mailman/listinfo/opensim-dev</a><br>
>>>><br>
>>>><br>
>>>><br>
>>>>
------------------------------------------------------------------------<br>
>>>><br>
>>>> _______________________________________________<br>
>>>> Opensim-dev mailing list<br>
>>>> <a href="http://mc/compose?to=Opensim-dev@lists.berlios.de" target="_blank">Opensim-dev@lists.berlios.de</a><br>
>>>> <a href="https://lists.berlios.de/mailman/listinfo/opensim-dev" target="_blank">https://lists.berlios.de/mailman/listinfo/opensim-dev</a><br>
>>>> <br>
>>> _______________________________________________<br>
>>> Opensim-dev mailing list<br>
>>> <a href="http://mc/compose?to=Opensim-dev@lists.berlios.de" target="_blank">Opensim-dev@lists.berlios.de</a><br>
>>> <a href="https://lists.berlios.de/mailman/listinfo/opensim-dev" target="_blank">https://lists.berlios.de/mailman/listinfo/opensim-dev</a><br>
>>><br>
>>><br>
>>><br>
>>>
------------------------------------------------------------------------<br>
>>><br>
>>> _______________________________________________<br>
>>> Opensim-dev mailing list<br>
>>> <a href="http://mc/compose?to=Opensim-dev@lists.berlios.de" target="_blank">Opensim-dev@lists.berlios.de</a><br>
>>> <a href="https://lists.berlios.de/mailman/listinfo/opensim-dev" target="_blank">https://lists.berlios.de/mailman/listinfo/opensim-dev</a><br>
>>> <br>
>> _______________________________________________<br>
>> Opensim-dev mailing list<br>
>> <a href="http://mc/compose?to=Opensim-dev@lists.berlios.de" target="_blank">Opensim-dev@lists.berlios.de</a><br>
>> <a href="https://lists.berlios.de/mailman/listinfo/opensim-dev" target="_blank">https://lists.berlios.de/mailman/listinfo/opensim-dev</a><br>
>><br>
>> <br>
> <br>
> _______________________________________________<br>
> Opensim-dev mailing list<br>
> <a href="http://mc/compose?to=Opensim-dev@lists.berlios.de" target="_blank">Opensim-dev@lists.berlios.de</a><br>
> <a href="https://lists.berlios.de/mailman/listinfo/opensim-dev" target="_blank">https://lists.berlios.de/mailman/listinfo/opensim-dev</a><br>
> <br>
> <br>
_______________________________________________<br>
Opensim-dev mailing list<br>
<a href="http://mc/compose?to=Opensim-dev@lists.berlios.de" target="_blank">Opensim-dev@lists.berlios.de</a><br>
<a href="https://lists.berlios.de/mailman/listinfo/opensim-dev" target="_blank">https://lists.berlios.de/mailman/listinfo/opensim-dev</a></p>
</div>
</td>
</tr>
</tbody></table>
<p><span style="font-size: 10pt;"> </span></p>
</div></div></div>
</div>
</div>
<br>_______________________________________________<br>
Opensim-dev mailing list<br>
<a href="mailto:Opensim-dev@lists.berlios.de">Opensim-dev@lists.berlios.de</a><br>
<a href="https://lists.berlios.de/mailman/listinfo/opensim-dev" target="_blank">https://lists.berlios.de/mailman/listinfo/opensim-dev</a><br>
<br></blockquote></div><br>