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

Sat Mar 14 18:40:57 UTC 2009

My understanding is that this question was originally supposed to be
more for non-UGAIMR services (I'm going to add 'region' into the
standard UGAIM since each logical [x,y]-referenced region has a single
logical endpoint -- while every other service has a single logical
endpoint for the entire grid, every individual region is a singleton
on the grid as well).

As such, if it's included in other projects, it should *NOT* have the
OpenSim prefix.  Maybe LibOpenSim, but not OpenSim.  This would allow
for easy identification of the segregation between the client portion
and the server portion.

(It would also allow for the creation of compatible classes that could
serialize out to the same data format that OpenSim's internal classes
deserialize themselves from.  For example, the use of UUID instead of
LUUID -- both serialize out to the same format, but the client could
be lean and mean and not have to worry about the object overhead that
LUUID imposes.  As well as removing an external dependency just to get
a single class definition.)

The downside is that it would require the serialization format (except
for well-defined things like UUIDs) to include a version specifier so
that the deserializer could figure out which version of the serializer
(and thus what assumptions) was used.  It would also require that code
be changed in two places every time a version bump occurred: a
serializer and deserializer would both need to be written in both
LibOpenSim and OpenSim.

-Kyle H

On Sat, Mar 14, 2009 at 4:38 AM, MW <michaelwri22 at yahoo.co.uk> wrote:
> Good questions.
>
> While OpenSim.Framework should be a general framework/library that can be
> used in other programs, it has very much turned out to be more of a internal
> framework for building the various opensim servers.
>
> Also there is a question of if opensim.framework should actually have
> service classes like your rest sending, or be more for the base classes and
> data structures.
>
> I really dislike the OpenSim.Framework.Communications project, as its turned
> out to really be a place where a lot of things have been dumped when we
> wasn't sure where else to put them. And I really want to split that up and
> cut it down. A lot of it will be moved out once I finish with moving the
> comms manager stuff to modules.
>
> So I think the best solution from where we find ourselves is to go with
> another namespace. Either OpenSim.Lib or OpenSim.Services. I've been
> thinking of a services namespace a little bit recently as there are a number
> of service classes/modules that could be shared between regions and UGAIM
> servers. So don't fit into either's namespace, but don't really fit in any
> of the existing framework namespaces either. Although I did also think of a
> OpenSim.Framework.Services namespace.
>
> Anyway I'm not sure about using OpenSimLib though, as all the rest of the
> namespaces have the OpenSim.XXXX format. So think we most likely should keep
> to that. So OpenSim.Lib?
>
> Hmm, also there is the opensim-lib part of svn where we keep things like our
> modifications to libomv. So is there going to be confusion with that?
>
> --- On Fri, 13/3/09, Diva Canto <diva at metaverseink.com> wrote:
>
> From: Diva Canto <diva at metaverseink.com>
> Subject: Re: [Opensim-dev] OpenSim dll for use by other programs
> To: opensim-dev at lists.berlios.de
> Date: Friday, 13 March, 2009, 11:50 PM
>
> 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
>
>