[Opensim-dev] Standardizing types in OpenSim

Wed Jan 7 13:00:31 UTC 2009

So,

should we have a go at this, then?

My _very_rough_ first outline proposal would be that we had something like

* A standard external base type library, with stuff like UUID, Vector3, Quaternion, et c. This would be used freely from all over core, and also, probably, in third party applications.
* A standard OpenSim base type library that defines very basic things like Agent, Avatar, Object/Entity, Scene - as interfaces or abstract classes implementing nothing but accessors and simple data manipulation. This would be freely used from all over core, and also in third party applications. This would only bring in the above library.
* A standard OpenSim base services type library that defines the service interfaces used, like IAssetServer, IAssetStore et c. This would only bring in the above libraries.

* A set of implementations of these base services, implementing actual behavior. These would bring in whatever needed, basically.

* The Client Views would bring in whatever third-party libraries they need.

/Stefan

> Date: Sat, 9 Aug 2008 15:23:30 +0900> From: sempuki1 at gmail.com> To: opensim-dev at lists.berlios.de> Subject: Re: [Opensim-dev] Standardizing types in OpenSim> > 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> >> _______________________________________________> Opensim-dev mailing list> Opensim-dev at lists.berlios.de> https://lists.berlios.de/mailman/listinfo/opensim-dev
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://opensimulator.org/pipermail/opensim-dev/attachments/20090107/bc77f7f8/attachment-0001.html>