[Opensim-dev] Standardizing types in OpenSim

Fri Aug 8 22:17:37 UTC 2008

Hrrm, there is some valid points nested in here - perhaps moving these out into a common library may be the way to go.

MetaverseTypes.dll anyone?

From: opensim-dev-bounces at lists.berlios.de [mailto:opensim-dev-bounces at lists.berlios.de] On Behalf Of Teravus Ovares
Sent: Friday, 8 August 2008 3:16 PM
To: opensim-dev at lists.berlios.de
Subject: Re: [Opensim-dev] Standardizing types in OpenSim

I start this letter by saying, I respect John and I agree on type standardization being important.

Having said that, I disagree that the libomv types are the types to standardize on.   Essentially what this means is we will be bringing libomv/libsecondlife /back/ into the core parts of opensimulator.   It's my understanding that we've spent countless hours trying to eliminate reliance on the library so that we are insulated from the breaking changes that we invariably see in libomv/libsecondlife between versions.

Also, to the 'trademark changes'...   no, we adopted this approach before all of the 'trademark related' changes.    We adopted this around LibSecondLife Revision 1550.   There were 3 non trademark breaking changes between the previous release version and this revision.  There was one breaking change between Revision 1450 and revision 1550.   Two of those breaking changes were subtle, meaning the compiler wouldn't notify you that something nasty happened.  I'll list the changes here for brevity;

1. LLUUID, LLVector3, and LLQuaternion were no longer serializable.   Base types *MUST* be serializable for Grid communications to work.   (Silent and nasty) (took approximately 8 man hours to resolve)

2. LLUUID.ToString() changed from the non dashed format to the dashed UUID format.   I still gawk when I think about this change.   The number of applications that were rendered completely useless by this change were many(select regionlocation from regions where RegionID='65e44815-6d70-4746-abaf-7a5f32272308' does not work if all of the data is stored '65e448156d704746abaf7a5f32272308'. (Silent and nasty) (took approximately 48 man hours to resolve)

3. In addition, several packet identification methods that we use extensively were removed. (took approximately 2 man hours to resolve)

Remember this is just *one* library update that all of this occurred on.    I know MW and lbsa have stories about extreme issues with previous libsecondlife updates.   (Caps, asset upload, XML format changes, TextureEntry changes, LLColor changes..   You name it, it's been a problem).

All in all, I'm 'seriously' suggesting that OpenSimulator maintain a set of base types that the project controls, or is in a dedicated library that is completely stable (Obviously not LibOMV/LibSecondLife).  Otherwise, somewhere down the line a LibOMV update will come that will cause OpenSimulator to fail and the devs will throw their arms up in frustration at the complete and utter arrogance that the libsecondlife project has shown of the effect API changes have on the users.

In IRC chat, you mentioned something along the lines of 'people must be waiting for someone else to do it' implying that the opensimulator devs are lazy.

This is not laziness, this is an attempt to avoid being masochistic.

Best Regards

Teravus

On 8/8/08, Frisby, Adam <adam at deepthink.com.au<mailto:adam at deepthink.com.au>> wrote:

I can +1 these patches in principle.

It's the 'in practice' that will need some fiddling as changing this many data types all at once is likely to cause an incredible amount of fun debugging later. (and will also mandate every grid update every region as our remoting support will break as a guarantee)

Regards,

Adam

From: opensim-dev-bounces at lists.berlios.de<mailto:opensim-dev-bounces at lists.berlios.de> [mailto:opensim-dev-bounces at lists.berlios.de<mailto:opensim-dev-bounces at lists.berlios.de>] On Behalf Of Charles Krinke
Sent: Friday, 8 August 2008 1:55 PM
To: opensim-dev at lists.berlios.de<mailto:opensim-dev at lists.berlios.de>
Subject: Re: [Opensim-dev] Standardizing types in OpenSim

Well, I'll merely say that I have the highest of respect for jhurliman's opinion and what he says here seems like a set of reasonable ideas.

Charles

----- Original Message ----
From: "Hurliman, John" <john.hurliman at intel.com<mailto:john.hurliman at intel.com>>
To: opensim-dev at lists.berlios.de<mailto:opensim-dev at lists.berlios.de>
Sent: Friday, August 8, 2008 11:44:59 AM
Subject: [Opensim-dev] Standardizing types in OpenSim

Hello list,

This is my first e-mail to opensim-dev so I'll start with an
introduction. I'm an engineer at Intel researching scalable models for
virtual worlds. A lot of the research will revolve around open,
user-generated content models like Second Life and OpenSim. I'm also the
primary developer of libOpenMetaverse (formerly libsecondlife, still
located at http://www.libsecondlife.org/ for the time being).

I've spent some time looking at the lower level components of OpenSim
and have a patch to propose. The basic type objects (vector, quaternion,
rays, etc) are spread out and duplicated over several internal classes
and external libraries. There are at least five different types of
Vector3, multiple quaternion and matrix classes, etc. Some of these are
classes instead of structs, meaning a basic operation like subtracting
two vectors and putting the result in a third creates several new
objects on the heap that the garbage collector has to track. I believe
this is responsible for a lot of the heavy memory and garbage collector
activity I am seeing. There is also a lot of duplicated code which has
led to incorrect constructors (such as new Vector3(x, y, y)) and makes
things more difficult to unit test.

The OpenMetaverse library has a set of types useful to virtual worlds
that have been in development for two years and implement all of the
functionality needed in OpenSim. I've created a very large patch that
upgrades OpenSim from libsecondlife to the latest libOpenMetaverse,
drops Axiom, and uses the built-in libomv types wherever possible. There
are a few places that I have skipped over for now to avoid introducing
too many moving parts in a single patch: BulletX still uses Mono.Xna,
and Meshmerizer still uses PhysicsVector/Vertex/Triangle.

I've spoken with some of the OpenSim developers about problems keeping
up with libsecondlife changes. The major changes happened to prevent a
trademark conflict with Linden Lab, and also establish libopenmv as a
generalized platform for building virtual worlds instead of a library to
connect to Linden Lab's servers. I think this patch is an important move
in that direction, and to prevent any future headaches I'm volunteering
to maintain the OpenSim->libOpenMetaverse dependency in the event of any
API changes.

I'm working on grid mode compatibility testing (sandbox mode appears to
work fine) and will have the patch on Mantis early to mid next week. So
far the patch itself weighs in around 1.7MB plus binaries. Twenty
revisions have passed since I initially wrote it and maintaining it
against the latest SVN can be time consuming, so I wanted to kick start
with this e-mail before posting the patch.

John Hurliman
_______________________________________________
Opensim-dev mailing list
Opensim-dev at lists.berlios.de<mailto:Opensim-dev at lists.berlios.de>
https://lists.berlios.de/mailman/listinfo/opensim-dev

_______________________________________________
Opensim-dev mailing list
Opensim-dev at lists.berlios.de<mailto:Opensim-dev at lists.berlios.de>
https://lists.berlios.de/mailman/listinfo/opensim-dev

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