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 <d...@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@lists.berlios.de > https://lists.berlios.de/mailman/listinfo/opensim-dev >
_______________________________________________ Opensim-dev mailing list Opensim-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/opensim-dev
