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