[Opensim-dev] Standardizing types in OpenSim

[Melanie]

+1 from me, too, on using the split-off types lib.

Can LLUUID be made serializable again, though?

Melanie


Justin Clark-Casey wrote:
> 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
> 
>