[Opensim-dev] Standardizing types in OpenSim

[Ryan McDougall]

+1, or +! as I almost wrote.

Cheers,

On Tue, Aug 19, 2008 at 8:13 AM, Hurliman, John <john.hurliman at intel.com> wrote:
> 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
> _______________________________________________
> Opensim-dev mailing list
> Opensim-dev at lists.berlios.de
> https://lists.berlios.de/mailman/listinfo/opensim-dev
>