[sldev] RE: Speed of adopting open practices (Re: IJIRA and PJIRA)

[Kent Quirk (Q Linden)]

On Jul 12, 2008, at 9:22 PM, Edward Artaud wrote:

>
> On Sat, Jul 12, 2008 at 4:53 PM, Lawson English <lenglish5 at cox.net>  
> wrote:
> Seriously, its a set of protocols (very limited at the moment) to  
> facilitate grid interop, and it eventually will become the basis for  
> a [more or less] complete redesign of the server architecture (I  
> suspect) and  even further off, the client (I hope).
>
>
> That was my concern when I was posting about the need for a plug-in  
> architecture.  Is it likely that OGP will yield anything useful for  
> the client until this time next year?  Most of the actual coding  
> will go into PyOGP, so by the end of the year, it'll be roughly  
> equivalent in terms of functionality to where libsl (openmv) is  
> today, but using the cleaner protocol and in Python rather than C#.   
> At that point, I suppose it'll need to be ported to C++ and somehow  
> bolted onto the SL viewer, which will take another 6 months, and  
> then we'll be roughly where we are today, but with a new underlying  
> protocol layer.  At that point, we'll be able to start refactoring  
> the viewer architecture.  I hope I'm wrong and it takes half that  
> time.

Please understand that there's no reasonable way to create a  
redesigned SL 2.0 from scratch that's independent of the current  
codebase. It's simply not practical to reinvent the wheel. For better  
or worse, we have to evolve our way to the next level.

What that means for things like OGP is that we need to follow the  
following sequence of events for each element of the protocols:

* Identify the protocol in question and define its scope
* Write the protocol specification
* Publish the spec and get feedback; iterate as necessary.
* Build the server side of the specification
* Independently build the client side test code from the specification  
only, to prove that it works and that it's possible to build a working  
test client from the specs alone
* Implement it in viewer code as an alternate path that falls back to  
the old code if it fails
* Deploy the server side in a test grid
* Ask people to try it out on the test grid
* Deploy server side on the main grid alongside the old path
* Run both versions in parallel for a while to make sure that it  
really works
* Obsolete the old version eventually
* Remove old code from the viewer

Some of these paths can be run in parallel for some parts of the  
protocol stack -- but the process simply takes a while. Part of the  
refactoring we're doing on the viewer is designed to make it easier to  
do some of these things. Part of the refactoring will be a result of  
moving our APIs behind well-defined protocols.

It's gonna take some time. But it's not a binary state -- we're trying  
to make continuous improvements. We'll never be "done", but hopefully  
a year from now things will look a lot better. And a year after that,  
better still.

	Q
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.secondlife.com/pipermail/sldev/attachments/20080714/bd72a78a/attachment-0001.htm