[Opensim-dev] Standardizing types in OpenSim

[Hurliman, John]

Thank you everyone who has responded, it sounds like there is a common
set of concerns that can be addressed.

* Taking advice from this thread, I split libOpenMetaverse into
OpenMetaverseTypes.dll and OpenMetaverse.dll, with the latter depending
on the former. OpenMetaverseTypes.dll is a very small library (64KB)
only containing UUID, Vector2, Vector3, Vector3d, Vector4, Quaternion,
Matrix4, Ray, Color4, and a static Utils class with common math and
conversion routines.

* An API freeze will happen immediately on the types library. I'll draft
up a wiki page to put it into more detail, but what this means
specifically is nothing will change names, no function signatures will
change, and the existing functions will behave the same throughout any
new revisions. New structs or functions may be added over time. It's
been in development for two years now, and I think the core
functionality is nailed down.

* The patch I wrote doesn't attempt to homogenize 100% of the types in
OpenSim. The LSL types serve a different function from the rest of the
types, and the PhysicsVector/Vertex/Triangle set is used in a unique way
that can't easily be replicated with a common type library. However,
there is a lot of room to go from five or six different implementations
down to two or three, and this patch errors on the side of caution in
that regard.

* libomv (and libomvtypes) will continue to be BSD licensed and do not
include any GPL licensed code. There is a separate GPL library for prim
meshing, but there is no dependency from libomv to the GPL mesher or
back, and the GPL code does not exist in the libomv SVN anywhere. It
will be released as a separate project for those who wish to use it.

The libomv team has been happy with the move toward independent modules
that break a lot of cyclic dependencies, and is generally going to be
the trend for new development in that library (including a Capability
server implementation). Let me know if anything else needs to be
addressed with the new types library. Some work needs to be done on my
end now to recreate the patch against the new OpenMetaverseTypes.dll.

-John


-----Original Message-----
From: opensim-dev-bounces at lists.berlios.de
[mailto:opensim-dev-bounces at lists.berlios.de] On Behalf Of Melanie
Sent: Friday, August 08, 2008 7:50 PM
To: opensim-dev at lists.berlios.de
Subject: Re: [Opensim-dev] Standardizing types in OpenSim

Hi,

I have to second the move for independence. Much time, also mine, 
has gone into removing or avoiding libsl references in core. Libsl 
has it's place in LLClientStack, where it provides connectivity to 
the one client that actually uses that protocol.

Countless hours have been spent to refactor _from_ libsl tyoes _to_ 
axiom, and the LSL implementations are different again, and need to 
be, if we want scripts to run unmodified, and, thinking onwards, 
achieve SL interoperability on a binary level.

Libomv seems to be a requirement only for the one use case of 
emulating SL, for any other scenario not using the SL client, that 
lib creates a huge amount of code overhead. Much of it isn't used in 
OpenSim as it stands.

Actually, it should even be broken up further.

libMetavrseTypes: Quaternion, Vector3, Color4, LLUUID, etc
libPackets: _Packets_.cs and the needed stuff to support using it.
libOpenMetaverse: All the rest, that OpenSim doesn't ever need.

Then libMetaverseTypes, which should have an API stability guarantee 
and whose types should be made serializable again, could be used 
throughout.

libPackets would be used in the LLClientStack exclusively

libOpenMetaverse would not be needed by this project.

Melanie

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