[Opensim-dev] Standardizing types in OpenSim

[Justin Clark-Casey]

Just want to say a 'me too' +1.  We all appear to be on the same page 
now and I think that reusing the hard work John and the rest of the 
libomv team have done is much better than writing our own stuff.

Dahlia Trimble wrote:
> Thanks for addressing those issues John :)
> 
> +1
> 
> On Mon, Aug 18, 2008 at 4:13 PM, Hurliman, John <john.hurliman at intel.com 
> <mailto: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>
>     [mailto: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 <mailto: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 <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
> 
> 
> 
> ------------------------------------------------------------------------
> 
> _______________________________________________
> Opensim-dev mailing list
> Opensim-dev at lists.berlios.de
> https://lists.berlios.de/mailman/listinfo/opensim-dev


-- 
justincc
Justin Clark-Casey
http://justincc.wordpress.com