[Opensim-dev] Object Representation

Wed Feb 13 08:56:00 UTC 2008

Here's my notes;> Object on the Wire - this definition comes from libsecondlife> Object in the code - SceneObjectPart / SceneObjectGroupWe have 'imported' a SL denormalization, the idea of the group properties being represented by a 'root' object, and the linkset not having an identity of its own, which has led to various weirdnesses as things like, for example, permissions, are linkset-wide. The protocol packets should be seen as _renditions_ of the 'object in code', ie we should create packets from a model, not the model from the packets.

Root object or no root object, the single prim should be seen as a link set with only one member; this introduces no extra overhead, but helps us think about the whole thing a bit more structured.

If anybody has a good way of thinking about the incestous relationship between the link set and the root prim, so that we can reach a model where the 'peer aspects' of parts are clearly separated from the 'node aspects' (child vs root), please step forward and state your case!
> Object in the code - SceneObjectPart / SceneObjectGroup> Object at rest - Database tables (which actually vary between db> backends)The database tables should actually be straightforward enough, possibly with some thought into how guids, vectors, quaternions, bit fields and enumerations should be stored; and also to what degree the normalization should be taken (ie, should we store the texturefaces of the textureentry in a separate table?)
What needs to be pondered is what compromises must be made in how the object model should look in order for persistence to work smoothly.

I have begun advocating us abstracting out 'model' base (or data) classes into a separate dll so that the model can be re-used outside the scope of OpenSim.exe, and I'd imagine that this would help with the database layer as well?
> Object at rest - Database tables (which actually vary between db> backends)> Object in XML - we have 2? versions of this already.
Actually, the XML serves (at least) three distinct purposes:
a) persistence into human-readable file format
b) exchange between services (OpenSim and others)
c) human and machine authoring (yes, believe it or not, but I think you should be able to write objects from scratch, by hand - and create simple code that outputs valid objects definitions)

The current xml format is a bare 'dump' of the scene/sceneobjectgroup/sceneobjectpart/shape structure, which leads to all kinds of messiness and duplication.

I have proposed that we start working on a third, and rather more 'final' xml format. I have looked into COLLADA, X3D (VRML) and some other format I forgot the acronym for, but none of them seemed to be useful in our setting. We need the format to be 1-to-1 mappable with our object model, which should be 1-to-1 mappable to the protocol, which looks like we have to brew our own, unfortunately.

Experience (from working with OpenSim-Xml since the beginning)  tells me we should start creating separate xml serialization(s) and not lean on the built-in.
> One of the challenges in getting to a grand unified scheme is that> all those representations are in some ways equal. Today they are> divergent enough that a lot of work is required at times to chunk them> into one form or another.
Alas, I suspect that we can't get around that; the in-mem has references, the database is (at heart) relational, and the xml hierarchical. Ideas or concepts suggesting otherwise very very welcome.

(Although, the xml can be made to work with references and we can base the data layer on an object model, it's... iffy.)
> So, here is your chance to be a hero in the OpenSim world. :) Ideas on> how to reasonably pull all this together to give us a much more> consistent serialization approach are very welcomed. Please pile on.
*piling*
> I think that solving this is probably our next big battle.

I think so too. 

> I'm excited> to see the NHibernate work getting very close, as I think that's a huge> step forward in this regard.

Ditto.

> This probably also means we need to bring> up the SOP/SOG discussion that Stephan wanted to kick off as well.
Without wanting to create a big hairball of things that need to be solved together and at once, I believe this relates to how we tackle 'attachments', which I'd say is our next big feature we NEED to get in place. (Apart from increased stability of course, and 'OGS2' which never seems to get addressed)

Best,
Stefan

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://opensimulator.org/pipermail/opensim-dev/attachments/20080213/be407784/attachment-0001.html>