<html xmlns:v="urn:schemas-microsoft-com:vml" xmlns:o="urn:schemas-microsoft-com:office:office" xmlns:w="urn:schemas-microsoft-com:office:word" xmlns:m="http://schemas.microsoft.com/office/2004/12/omml" xmlns="http://www.w3.org/TR/REC-html40">
<head>
<meta http-equiv=Content-Type content="text/html; charset=us-ascii">
<meta name=Generator content="Microsoft Word 12 (filtered medium)">
<style>
<!--
/* Font Definitions */
@font-face
{font-family:"Cambria Math";
panose-1:2 4 5 3 5 4 6 3 2 4;}
@font-face
{font-family:Calibri;
panose-1:2 15 5 2 2 2 4 3 2 4;}
@font-face
{font-family:Tahoma;
panose-1:2 11 6 4 3 5 4 4 2 4;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
{margin:0in;
margin-bottom:.0001pt;
font-size:12.0pt;
font-family:"Times New Roman","serif";}
a:link, span.MsoHyperlink
{mso-style-priority:99;
color:blue;
text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
{mso-style-priority:99;
color:purple;
text-decoration:underline;}
p.MsoListParagraph, li.MsoListParagraph, div.MsoListParagraph
{mso-style-priority:34;
margin-top:0in;
margin-right:0in;
margin-bottom:0in;
margin-left:.5in;
margin-bottom:.0001pt;
font-size:12.0pt;
font-family:"Times New Roman","serif";}
span.EmailStyle17
{mso-style-type:personal-reply;
font-family:"Calibri","sans-serif";
color:#1F497D;}
.MsoChpDefault
{mso-style-type:export-only;}
@page Section1
{size:8.5in 11.0in;
margin:1.0in 1.0in 1.0in 1.0in;}
div.Section1
{page:Section1;}
/* List Definitions */
@list l0
{mso-list-id:766315855;
mso-list-type:hybrid;
mso-list-template-ids:2115502486 67698705 67698713 67698715 67698703 67698713 67698715 67698703 67698713 67698715;}
@list l0:level1
{mso-level-text:"%1\)";
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-.25in;}
ol
{margin-bottom:0in;}
ul
{margin-bottom:0in;}
-->
</style>
<!--[if gte mso 9]><xml>
<o:shapedefaults v:ext="edit" spidmax="1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
<o:shapelayout v:ext="edit">
<o:idmap v:ext="edit" data="1" />
</o:shapelayout></xml><![endif]-->
</head>
<body lang=EN-US link=blue vlink=purple>
<div class=Section1>
<p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'>This discussion went west pretty fast it seems.<o:p></o:p></span></p>
<p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'><o:p> </o:p></span></p>
<p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'>To try to get things on track; this is what I’ve heard said,
and proposed, in roughly this proposed order:<o:p></o:p></span></p>
<p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'><o:p> </o:p></span></p>
<p class=MsoListParagraph style='text-indent:-.25in;mso-list:l0 level1 lfo1'><![if !supportLists]><span
style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'><span
style='mso-list:Ignore'>1)<span style='font:7.0pt "Times New Roman"'>
</span></span></span><![endif]><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'>The BUST architecture might or might not change name. *<b>This
is a separate item for discussion</b>*.<o:p></o:p></span></p>
<p class=MsoListParagraph style='text-indent:-.25in;mso-list:l0 level1 lfo1'><![if !supportLists]><span
style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'><span
style='mso-list:Ignore'>2)<span style='font:7.0pt "Times New Roman"'>
</span></span></span><![endif]><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'>The BUST architecture should be documented. This documentation
is allegedly on the way, but should be seen as a work in progress, like always.<o:p></o:p></span></p>
<p class=MsoListParagraph style='text-indent:-.25in;mso-list:l0 level1 lfo1'><![if !supportLists]><span
style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'><span
style='mso-list:Ignore'>3)<span style='font:7.0pt "Times New Roman"'>
</span></span></span><![endif]><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'>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.<o:p></o:p></span></p>
<p class=MsoListParagraph style='text-indent:-.25in;mso-list:l0 level1 lfo1'><![if !supportLists]><span
style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'><span
style='mso-list:Ignore'>4)<span style='font:7.0pt "Times New Roman"'>
</span></span></span><![endif]><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'>The Cable Beach offspring AssetInventoryServer might or might
not move out of core. *<b>This is a separate item for discussion</b>*.<o:p></o:p></span></p>
<p class=MsoListParagraph style='text-indent:-.25in;mso-list:l0 level1 lfo1'><![if !supportLists]><span
style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'><span
style='mso-list:Ignore'>5)<span style='font:7.0pt "Times New Roman"'>
</span></span></span><![endif]><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'>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>*. <o:p></o:p></span></p>
<p class=MsoListParagraph style='text-indent:-.25in;mso-list:l0 level1 lfo1'><![if !supportLists]><span
style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'><span
style='mso-list:Ignore'>6)<span style='font:7.0pt "Times New Roman"'>
</span></span></span><![endif]><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'>Whether this new protocol should be developed in or outside of
trunk is part of that separate discussion.<o:p></o:p></span></p>
<p class=MsoListParagraph style='text-indent:-.25in;mso-list:l0 level1 lfo1'><![if !supportLists]><span
style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'><span
style='mso-list:Ignore'>7)<span style='font:7.0pt "Times New Roman"'>
</span></span></span><![endif]><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'>BUST will allow OGS1 and OGS2 to exist side by side.<o:p></o:p></span></p>
<p class=MsoListParagraph style='text-indent:-.25in;mso-list:l0 level1 lfo1'><![if !supportLists]><span
style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'><span
style='mso-list:Ignore'>8)<span style='font:7.0pt "Times New Roman"'>
</span></span></span><![endif]><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'>OGS1 might or might not be retired. *<b>This is a separate item
for discussion</b>*<o:p></o:p></span></p>
<p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'><o:p> </o:p></span></p>
<p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'>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.<o:p></o:p></span></p>
<p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'><o:p> </o:p></span></p>
<p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'>Just to put things in perspective, I would estimate bullets 5-8 probably
to be during 2010. Point 8 probably more around early 2011.<o:p></o:p></span></p>
<p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'><o:p> </o:p></span></p>
<p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'>/Stefan<o:p></o:p></span></p>
<p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'><o:p> </o:p></span></p>
<div style='border:none;border-left:solid blue 1.5pt;padding:0in 0in 0in 4.0pt'>
<div>
<div style='border:none;border-top:solid #B5C4DF 1.0pt;padding:3.0pt 0in 0in 0in'>
<p class=MsoNormal><b><span style='font-size:10.0pt;font-family:"Tahoma","sans-serif"'>From:</span></b><span
style='font-size:10.0pt;font-family:"Tahoma","sans-serif"'> opensim-dev-bounces@lists.berlios.de
[mailto:opensim-dev-bounces@lists.berlios.de] <b>On Behalf Of </b>MW<br>
<b>Sent:</b> den 9 juli 2009 02:43<br>
<b>To:</b> opensim-dev@lists.berlios.de<br>
<b>Subject:</b> Re: [Opensim-dev] Deprecate OpenSim.Grid.InventoryServer and
OpenSim.Grid.AssetServer?<o:p></o:p></span></p>
</div>
</div>
<p class=MsoNormal><o:p> </o:p></p>
<table class=MsoNormalTable border=0 cellspacing=0 cellpadding=0>
<tr>
<td valign=top style='padding:0in 0in 0in 0in'>
<p class=MsoNormal>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><melanie@t-data.com></i></b> wrote:<o:p></o:p></p>
<p class=MsoNormal style='margin-bottom:12.0pt'><br>
From: Melanie <melanie@t-data.com><br>
Subject: Re: [Opensim-dev] Deprecate OpenSim.Grid.InventoryServer and
OpenSim.Grid.AssetServer?<br>
To: opensim-dev@lists.berlios.de<br>
Date: Wednesday, 8 July, 2009, 11:42 PM<o:p></o:p></p>
<div>
<p class=MsoNormal>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="/mc/compose?to=melanie@t-data.com">melanie@t-data.com</a>><br>
>>> To: <a href="/mc/compose?to=opensim-dev@lists.berlios.de">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="/mc/compose?to=melanie@t-data.com">melanie@t-data.com</a>><br>
>>>> To: <a href="/mc/compose?to=opensim-dev@lists.berlios.de">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="/mc/compose?to=melanie@t-data.com">melanie@t-data.com</a>> wrote:<br>
>>>>><br>
>>>>> From: Melanie <<a
href="/mc/compose?to=melanie@t-data.com">melanie@t-data.com</a>><br>
>>>>> Subject: Re: [Opensim-dev] Deprecate
OpenSim.Grid.InventoryServer and OpenSim.Grid.AssetServer?<br>
>>>>> To: <a href="/mc/compose?to=opensim-dev@lists.berlios.de">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="/mc/compose?to=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>
>>>>><br>
>>>>><br>
>>>>> <br>
>>>>><br>
>>>>><br>
>>>>>
------------------------------------------------------------------------<br>
>>>>><br>
>>>>> _______________________________________________<br>
>>>>> Opensim-dev mailing list<br>
>>>>> <a href="/mc/compose?to=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>
>>>> _______________________________________________<br>
>>>> Opensim-dev mailing list<br>
>>>> <a href="/mc/compose?to=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>
>>>><br>
>>>><br>
>>>>
------------------------------------------------------------------------<br>
>>>><br>
>>>> _______________________________________________<br>
>>>> Opensim-dev mailing list<br>
>>>> <a href="/mc/compose?to=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>
>>> _______________________________________________<br>
>>> Opensim-dev mailing list<br>
>>> <a href="/mc/compose?to=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>
>>><br>
>>><br>
>>>
------------------------------------------------------------------------<br>
>>><br>
>>> _______________________________________________<br>
>>> Opensim-dev mailing list<br>
>>> <a href="/mc/compose?to=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>
>> _______________________________________________<br>
>> Opensim-dev mailing list<br>
>> <a href="/mc/compose?to=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>
>> <br>
> <br>
> _______________________________________________<br>
> Opensim-dev mailing list<br>
> <a href="/mc/compose?to=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>
> <br>
_______________________________________________<br>
Opensim-dev mailing list<br>
<a href="/mc/compose?to=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><o:p></o:p></p>
</div>
</td>
</tr>
</table>
<p class=MsoNormal><span style='font-size:10.0pt;font-family:"Calibri","sans-serif"'><o:p> </o:p></span></p>
</div>
</div>
</body>
</html>