[Opensim-dev] OpenSim dll for use by other programs

Sat Mar 14 20:07:25 UTC 2009

Well.

The dependancy on libomv has always been a topic for discussion. I included it as a fairly reasonable compromise to get the vector and quaternion types and transformations that we are operating with.

My point is exactly that, that the number of dependencies has to go down, and the way to do it is to introduce a types layer, a services layer and an application layer, where the application layer is the one that draws in the most dependencies. The types layer should bring in a bare minimum (system and needed math types) since it will be geared towards reuse in any application, the services layer might bring in a few more.

What you are proposing is something you could set up a forge project to do today - problem is that such an 'third party' lib will have to be maintained and in synch in just the same way we have to be kept in synch with libomv. If it's in the core repo, it should follow the core naming conventions.

I'm proposing we create something that can function both for our own core and for third parties. Kind of like Axiom has (had?) its Mathlib.

Best regards,
Stefan Andersson
Tribal Media AB

> Date: Sat, 14 Mar 2009 11:44:10 -0700
> From: aerowolf at gmail.com
> To: opensim-dev at lists.berlios.de
> Subject: Re: [Opensim-dev] OpenSim dll for use by other programs
> 
> I don't really believe that a single namespace is all that possible.
> OpenSim itself has too many external dependencies, and your suggestion
> for OpenSim.Model would expose those dependencies to external
> programs. (do we want to expose the requirement for libomv to be
> linked to get a class structure referenced from OpenSim.Model, when
> all the client wanted was to be able to edit a mesh without uploading
> it?)
> 
> -Kyle H
> 
> On Sat, Mar 14, 2009 at 6:09 AM, Stefan Andersson <stefan at tribalmedia.se> wrote:
> > I have on several occasions suggested the OpenSim.Model project approach,
> > that would contain base data structures, as a base for any application that
> > wants to interact or modify OpenSim data structures.
> >
> > I think this could be done in steps with a minimum of architectural fussing
> > about.
> >
> > 1) First thing would probably be to create the OpenSim.Model.Interfaces
> > namespace (in the OpenSim.Model project) and just move any interface that
> > doesn't reference any other types than system types or libomv types there.
> > Just move those ther, plain and simple.
> >
> > 2) Second, we could start moving OpenSim base types, ie, extract abstract
> > superclasses on all root classes containing only their data containers, and
> > move them to OpenSim.Model. This should meet no problems, just moving them.
> > There are excellent refactoring tools for this.
> >
> > Third, we could have another round at a)
> >
> > et c
> >
> > this is a process that can be started today, and is more about code hygiene
> > than architectural pridence.
> >
> > at some point, we should probably establish the
> > OpenSim.Framework.Serialization that would more or less only reference
> > OpenSim.Model, which is used to contain all those classes and functions that
> > are used to serialize base objects back and forth to various supported core
> > formats.
> >
> > Similarly, but not connected, I believe that a separate project,
> > OpenSim.Services is the right way to go. It's the layer right above the
> > application layer (which can't be generalized into one project, as
> > each executable needs its own assembly)
> >
> > Best regards,
> > Stefan Andersson
> > Tribal Media AB
> >
> >
> >
> >
> > ________________________________
> > Date: Fri, 13 Mar 2009 16:50:51 -0700
> > From: diva at metaverseink.com
> > To: opensim-dev at lists.berlios.de
> > Subject: Re: [Opensim-dev] OpenSim dll for use by other programs
> >
> > Here's a suggestion.
> >
> > We could have another project under OpenSim called
> > OpenSimLib
> > This would be a place for putting things that are meant to be used both by
> > OpenSim and by other programs.
> > We could start with
> > OpenSimLib.Communications
> > OpenSimLib.Meshes
> >
> > I suspect several data structures would move there.
> >
> > But this raises the question about OpenSim.Framework -- is it supposed to be
> > _that_ OpenSimLib? I see some of that, but it's mostly assuming that the
> > "other programs", other than OpenSim.exe, are exactly the 5 U G A I M
> > servers. I'm now thinking that clients (all sorts of clients) will want to
> > use some of that too.
> >
> > Yeah, maybe OpenSim.Framework is the right place to put this kind of code?
> > What do you think? Should I move the sending side functions of RESTComms to
> > OpenSim.Framework.Communications?
> >
> >
> >
> > Diva Canto wrote:
> >
> > Cool, I'm glad to see there are more cases.
> > In my case, this piece of comm needs stuff from OpenSim.Framework
> > (RegionInfo, AgentCircuitData) and other data structures from other places
> > in opensim (Region.Framework.Scenes.AgentData), which is a bit of a mess
> > that needs to be cleaned up too.
> >
> > [RegionInfo, btw, is E.V.I.L -- I've wasted several hours over the past
> > several months fighting with the ExternalEndPoint property. I always get it
> > wrong. If we are to expose something like that to other fellow humans, I'll
> > probably define another, much simpler, data structure.]
> >
> >
> > Dahlia Trimble wrote:
> >
> > I had a similar intention with Primmesher. Currently there is a
> > primmesher.dll project on forge which is a dll containing the 2 files
> > Primmesher.cs and Sculptmesh.cs. My intent was to have a single dll file
> > which could be used by both OpenSim and viewer projects wishing to implement
> > prims and sculpties. In order to make this a standalone dll I had to create
> > internal types for quaternions and vectors, and the associated methods and
> > operators. In this case it is a small duplication of code in other modules
> > in OpenSim, but it's probably ok as I needed to extend those types while
> > coding Primmesher anyway. The code on forge and in OpenSim are identical and
> > one could easily delete those 2 files from OpenSim and just use the dll file
> > from forge. This was my intent but I ran into some difficulties with
> > prebuild.xml and the location of the dll file in the physics folder in the
> > OpenSim tree, as it would not build successfully on some systems. So for now
> > I am maintaining both source trees and keeping the code in sync.
> >
> > On Fri, Mar 13, 2009 at 1:50 PM, Diva Canto <diva at metaverseink.com> wrote:
> >
> > I need more architectural advice.
> >
> > I'm working on a client that has all the control over the agents. For
> > that, it uses the sending part of the RESTInterregionComms module that I
> > did a couple of months ago -- a module which now is clearly out of
> > place. That module is not about interregion comms; it's about comms
> > involving regions, but not necessarily *between* regions. In my case,
> > it's between the client and the region. I'm "using
> > OpenSim.Region.CoreModules.Communications.REST" in my client -- horrible.
> >
> > So, I want to break it down into 2 parts, sending and receiving. The
> > question is: where should I place these two parts? The receiving part
> > can continue to be a region module in CoreModules -- that's perfectly
> > fine. But how about the sending part?
> >
> > The sending part needs to be in a dll that can be used by other programs
> > out there, just like my client. This is, in fact, what will make OpenSim
> > interoperable from the  outside -- its use API, as opposed to the
> > wonderful extension API provided by region modules. Should these things
> > be in OpenSim.Framework.*? I was tempted to think so, but then I looked
> > at what's in there, and it's clearly facing the internals. Should it be
> > in OpenSim.Region.Communications.*?
> > OpenSim.Region.CoreModules.Communications.REST with sending and
> > receiving parts as separate modules? (but then the importers of this
> > will get all the other CoreModules as a dll, which doesn't feel right)
> >
> > Your thoughts appreciated. Just think of what makes sense from a program
> > that wants to use OpenSim libraries.
> >
> > _______________________________________________
> > 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
> >
> >
> > ________________________________
> > _______________________________________________
> > 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
> >
> >
> _______________________________________________
> 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/20090314/ebd7fa94/attachment-0001.html>