[Opensim-dev] User services refactoring status

diva at metaverseink.com diva at metaverseink.com
Wed Jan 6 16:10:34 UTC 2010


Tom Willans wrote:
> Are some aspects of the interface more settled than others? I appreciate 
> that this is a judgement call.

Yes, some aspects are more settled than others.
First, let me point out where this comes from, so that you and others 
can understand better.

Up to recently, there was no such thing as OpenSim.Services.Interfaces, 
nor the companions OpenSim.Services.Connectors and 
OpenSim.Server.Handlers. The interaction between the simulator and the 
resource services, and among the resource services themselves, was a 
mess. I don't mean it in a criticizing attitude, early-stage code is 
usually a mess. The broad stokes were there, and were really good, but 
the details were a complete mess. Simple questions like "what handlers 
are there?" or "what are the resource service interfaces?" were a 
challenge to answer, interfaces and handlers were spread all over the 
code, special cases were pervasive, classes were being used directly 
instead of interfaces, etc. The user services, in particular, were a 
nightmare, with duplication running rampant because of "standalone vs 
grid mode", and the code being on the verge of bipolar disorder. Users, 
agents and avatars were being used interchangeably, with no conceptual 
distinction, misnomers everywhere, etc.

This refactoring's main goal is to depart from that chaotic mess and to 
instill order in the code base. It is primarily a *refactoring*, meaning 
that code has moved from one namespace to another, but it is also a 
rewrite -- because in the process of revisiting the code it was clear 
that things should be done better than they were being done. In 
particular, harmful hard-coded instantiations of classes were replaced 
by dynamic loading and instantiation. The core of this is 
OpenSim.Server.Base.Utils.LoadPlugin -- this is the core of the ROBUST 
model.

Having said that, let me now explain how people who plan to extend 
OpenSim should be looking at it.

The main "contract" between the core code and developers of resource 
services is the collection of interfaces in OpenSim.Services.Interfaces. 
This is what the simulators call, can't get around hard-coded calls to 
those interfaces. Those interfaces will stabilize very quickly. Most of 
them are stable already, with the notable exception of IInventoryService 
which still needs love. But all others will be stable at 0.7. Now is the 
right time for people to look at those interfaces and send feedback 
about which things you think are missing.

The next level of reuse is the code in OpenSim.Services.Connectors and 
OpenSim.Server.Handlers. This code is less important than the 
interfaces, because it's invisible to the simulators, therefore ppl 
should be more careful about relying on it. This is quite an important 
point that I don't think many people grasp yet, so let me explain.

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.

So, to sum it up: the main contract is OpenSim.Services.Interfaces and 
those are going to be stable very soon. The level right under it, 
OpenSim.Server.Handlers and OpenSim.Services.Connectors can also be 
relied upon but it's less stable. I'm still not happy with many of 
those, so they will change after 0.7. People who don't want to put up 
with these changes may want to roll their own network protocols.



More information about the Opensim-dev mailing list