[Opensim-dev] User services refactoring status

[diva at metaverseink.com]

A perfectly valid position; a dilemma for people who like OpenSim so 
much that hate having to wait for 1.0 to make cool things with it. 
Forking is always an option, especially for organizations who have the 
resources to support the fork. Personally, I'd be sad if you decide to 
fork, since the Intel devs are super-duper contributors to OpenSim. But, 
obviously, I understand the need for a layer between raw development and 
end users... and that's one thing that the OpenSim project has sucked at 
really bad, intentionally or not.

Ad-nausum protocol discussions: I've been in those meetings before. Not 
here, and not anymore. Since reflection came into mainstream PLs, you 
can now avoid those discussions by adding a meta-level, and that's what 
happened here :) XMLRPC vs REST vs LLx? Protocol buffers vs .NET 
serialization? - have it your way, the simulator doesn't care, it only 
sees interfaces. For example, it looks like it's going to be possible to 
rewrite OGP as a different handler for the simulation service... but 
that's a different conversation.

Mic Bowman wrote:
> The comment below about ad-nauseum discussions is at least a 
> mis-representation and borders on silly. This isn't an "either/or" 
> situation. You can have discipline, documentation, and well thought out 
> interfaces *AND* make rapid progress.
> 
> OpenSim development has chosen a more-than-usual "anarchist" process 
> (anarchist is the word I've heard core developers use to describe 
> themselves)... and that's a very reasonable choice for this project (and 
> a choice that is clearly communicated). Its an approach that leads to 
> rapid innovation and (to put it mildly) passionate energy in the coding.
> 
> It also has other consequences... For example, it alienates the "user" 
> community who would like to take the code, use it and extend it. Yes.. 
> you can claim that we're all too early. That we should wait for 1.0. 
> Until then, for all its claims to extensibility, the cost of maintaining 
> extensions against a shifting-sand set of interfaces is very high... 
> that is, the development process that has been chosen for OpenSim works 
> against the basic goals of the project.
> 
> The normal response to this kind of message is "get in and fix it". And 
> I completely agree. And we have (financial support, code, marketing, 
> etc). And... the question we continue to ask ourselves is whether our 
> (meaning Intel) dev resources would be better focused on work specific 
> to our customers & collaborators on a release we choose to "freeze" or 
> whether we should continue to wait for and work towards 1.0.
> 
> Please note that I'm not suggesting that OpenSim core development change 
> (or we would lose all the benefits of the process)... I'm simply saying 
> that the current development process forces us as users to decide when 
> the platform has reached an appropriate level of functionality and to 
> focus our resources on that version.
> 
> --mic
>  
> On Wed, Jan 6, 2010 at 8:10 AM, <diva at metaverseink.com 
> <mailto:diva at metaverseink.com>> wrote:
> 
>     In most systems, the network protocols are fixed. People go to great
>     lengths discussing them ad-nauseum in meetings and committees, to settle
>     on the right data formats, the right data, etc. NOT HERE. The network
>     protocols in OpenSim are now dynamically loaded, and therefore
>     replaceable. There is no such thing as *the* network protocol between
>     the simulator and, say, the asset server. There can be many -- you can
>     roll your own. There are reference implementations in the core
>     distribution, but that's exactly what they are: reference
>     implementations, they are not fixed protocols. As such, people should be
>     careful about relying on those reference implementations.
> 
>