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

Diva Canto diva at metaverseink.com
Fri Mar 13 23:50:51 UTC 2009


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 
>> <mailto: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 <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
>>   
>
> ------------------------------------------------------------------------
>
> _______________________________________________
> 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/20090313/d4a7fff4/attachment-0001.html>


More information about the Opensim-dev mailing list