It's really difficult to have a meaningful conversation about the future
of OpenSimulator without understanding what OpenSimulator really is,
from a technical perspective.
Dahlia and Misterblue already mentioned it, but I'll mention it
again.OpenSimulator, as designed by this particular team of developers,
is a framework or an application server, not a complete product. It's
full of hooks so that people can create their own products while having
a good jump start with a bunch of default application behavior. So, off
the box, it looks like SL (plus a few goodies), as that seems to be the
default behavior that most people are/were interested in, to leverage
the existence of the SL viewers; but if you want, it can be made to look
like something completely different.
The best analogy for what OpenSimulator is is this (courtesy of Apple):
https://developer.apple.com/library/mac/referencelibrary/GettingStarted/RoadMapOSX/books/IntegrateYourCodewiththeFrameworks/Art/house_framework.png
At its core, embodied in the dll OpenSim.Region.Framework, it's a 3d
scene manager. That's about it; that's all that's hardcoded. The scene
manager interacts with the rest of the software via a number of
interfaces that are expected to be implemented in some way or another,
and that are all dynamically loaded via an external specification
(plugins). Most notably, there are interfaces for: user clients,
physics, scripting, numerous backend resource services, data storage
providers, and a generic interface for adding any kind of additional
features to the scene manager (aka "Region Modules" given by the mono
addin extension point /OpenSim/RegionModules). There is also an even
lower-level generic interface that allows the injection of additional
features at the server level (given by the mono addin extension point
/OpenSim/Startup).
Just above that core, embodied by several other dynamically loaded dlls,
there is the default application behavior of SL, with almost
feature-full support for the LL protocol
(OpenSim.Region.ClientStack.LindenUDP.dll and many others). This
behavior can be replaced by providing other dlls that implement the same
interfaces. So if you want to support any other client protocol, you
can, by implementing the corresponding interface that the scene manager
expects clients to have.
Using that Apple image of what a framework is, people can have lots of
ideas for how their favorite house will look like. I have mine. But
that's not what OpenSimulator is. OpenSimulator is the framework, plus
the default "Linden house" that can be replaced entirely.
Having explained that, the conversation about the future of
OpenSimulator is a conversation about the future of the framework and
default application behavior that comes with it, not about any
particular alternative "house." There can be separate conversations
about alternative houses, but I doubt they will be of interest to the
exact same team that has built, and is building, the framework.
So what kinds of topics should we talk about when discussing the future
of the framework? Here are some:
1 - The APIs. Some APIs are already pretty solid and flexible, others
are a complete mess. The client API, for example, is a fur ball, because
it is meant to be a generic client API but so far we have had only one
type of client. Unfortunately, it's hard to untangle that fur ball
without having at least another type of client that comes in and
challenges the assumptions made very early on.
2 - Leakage from the Linden application onto the core of the framework.
The picture I painted is very compelling (I hope!) but the reality is
just a little bit different. From early on, there was some leakage from
the design of the Linden house onto the core of the framework. For
example, the data structures we use for modeling 3d scenes are heavily
influenced by how the Linden viewers expect things. It would be nice to
drain the core from that influence. This will be a major undertaking,
and I don't know who among us has time/motivation to do it, but I know
that there have been designs and plans to do it, which unfortunately
didn't pan out.
3 - Documentation of the framework. Community-led open source projects
tend to fare really poorly on this, and OpenSimulator is no exception.
The Wiki is a mess. The code has been the most reliable documentation so
far (for me, at least), followed by asking questions on the IRC. This
raises the bar for what kinds of people can develop addons for
OpenSimulator; people who are comfortable with reading tons of code and
asking questions to complete strangers eventually start to understand
how the framework is architected; people who need to read English get
frustrated and go away. Maybe not a bad entrance criteria for a while,
but if we want more action on the kinds of houses people build, the bar
needs to be lowered by providing documentation. I don't have a solution
for this, because translating from C# to English is a boring job that no
core developer is willing to do [for free], but I sure would love to see
some action!
4 - The ease of finding and sharing alternative implementations of APIs
from 3rd party developers. This one is pretty high up on my priority
list and, in my view, it's the single major technical goal that needs to
be achieved before we can tag 1.0. Without a package distribution system
that connects providers and consumers, frameworks are of very little
use; the only way we can help connect them is to add more things to the
core package, which is alarming -- complexity of software grows
exponentially with the number of modules, not linearly. I have been
experimenting with the mono addins package manager for my own addons;
I'll have more information of how that really fares on the next release,
when some people will have to upgrade my addons using the package
manager command line tool.
5 - The default "house." There is no question in my mind that this needs
some repairs, and I am really happy with how much closer we have been
working with viewer developers. Realistically, this evolution will be
not be a radical departure from what SL is, it will be just a bunch of
small improvements, hopefully leading to viewers that are a lot more
secure and programmable. For radical departures, see above my
description of OpenSimulator and the previous point 4 for how to connect
these more radical "houses" to potential consumers.
_______________________________________________
Opensim-dev mailing list
[email protected]
http://opensimulator.org/cgi-bin/mailman/listinfo/opensim-dev
