[Opensim-dev] Standardizing types in OpenSim

[Ryan McDougall]

I suspect we could go back and forth on this matter for quite a while
without resolution.

I think everyone agrees that we should have a common set of primitive
types, but there are a lot of question marks and concerns that need to
be addressed first. To avoid talking in circles, I propose that some
sort of semi-formal proposal to be made to this list and debated on
the merits therein.

If John thinks classes from libomv should be used, he can list his
motivations, rationalizations, pro/cons, and alternatives. If a party
thinks axiom is the way to go forward, they should do likewise, and we
can have this discussion publicly on the actual merits of each
proposal.

Only *after* the proposal is accepted, can we then consider the
details of John's or others' patches.

For an example of how such a process has worked successfully for many
years in another open source project:
http://www.python.org/dev/peps/pep-0001
http://www.python.org/dev/peps/pep-0001/#what-belongs-in-a-successful-pep

also
http://live.gnome.org/ReleasePlanning/ModuleProposing
http://developer.gnome.org/gep/gep-0.html

Cheers,

On Sat, Aug 9, 2008 at 3:44 AM, Hurliman, John <john.hurliman at intel.com> wrote:
> 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
> https://lists.berlios.de/mailman/listinfo/opensim-dev
>