[Opensim-dev] Standardizing types in OpenSim

Wed Jan 7 06:15:22 UTC 2009

"* 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."
This has to be very thin and don't contain any fancy code or
dependencies as it needs to be loaded into AppDomains for scripts.
Better to keep it save by design that to configure too much security on
AppDomain.

From: opensim-dev-bounces at lists.berlios.de
[mailto:opensim-dev-bounces at lists.berlios.de] On Behalf Of Stefan
Andersson
Sent: 7. januar 2009 14:01
To: opensim-dev at lists.berlios.de
Subject: Re: [Opensim-dev] Standardizing types in OpenSim

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-pe
p
> 
> 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/96571943/attachment-0001.html>