<table cellspacing="0" cellpadding="0" border="0" ><tr><td valign="top" style="font: inherit;">Good questions. <br><br>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. <br><br>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. <br><br>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.<br><br>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.<br><br>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?<br><br>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?<br><br>--- On <b>Fri, 13/3/09, Diva Canto <i><diva@metaverseink.com></i></b> wrote:<br><blockquote style="border-left: 2px solid rgb(16, 16, 255); margin-left: 5px; padding-left: 5px;">From: Diva Canto <diva@metaverseink.com><br>Subject: Re: [Opensim-dev] OpenSim dll
for use by other programs<br>To: opensim-dev@lists.berlios.de<br>Date: Friday, 13 March, 2009, 11:50 PM<br><br><div id="yiv1011889559">
Here's a suggestion.<br>
<br>
We could have another project under OpenSim called<br>
OpenSimLib<br>
This would be a place for putting things that are meant to be used both
by OpenSim and by other programs.<br>
We could start with<br>
OpenSimLib.Communications<br>
OpenSimLib.Meshes<br>
<br>
I suspect several data structures would move there.<br>
<br>
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.<br>
<br>
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?<br>
<br>
<br>
<br>
Diva Canto wrote:
<blockquote type="cite">
Cool, I'm glad to see there are more cases.<br>
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.<br>
<br>
[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.]<br>
<br>
<br>
Dahlia Trimble wrote:
<blockquote type="cite">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.<br>
<br>
<div class="gmail_quote">On Fri, Mar 13, 2009 at 1:50 PM, Diva
Canto <span dir="ltr"><<a rel="nofollow" target="_blank" href="mailto:diva@metaverseink.com">diva@metaverseink.com</a>></span>
wrote:<br>
<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">I
need more architectural advice.<br>
<br>
I'm working on a client that has all the control over the agents. For<br>
that, it uses the sending part of the RESTInterregionComms module that I<br>
did a couple of months ago -- a module which now is clearly out of<br>
place. That module is not about interregion comms; it's about comms<br>
involving regions, but not necessarily *between* regions. In my case,<br>
it's between the client and the region. I'm "using<br>
OpenSim.Region.CoreModules.Communications.REST" in my client --
horrible.<br>
<br>
So, I want to break it down into 2 parts, sending and receiving. The<br>
question is: where should I place these two parts? The receiving part<br>
can continue to be a region module in CoreModules -- that's perfectly<br>
fine. But how about the sending part?<br>
<br>
The sending part needs to be in a dll that can be used by other programs<br>
out there, just like my client. This is, in fact, what will make OpenSim<br>
interoperable from the outside -- its use API, as opposed to the<br>
wonderful extension API provided by region modules. Should these things<br>
be in OpenSim.Framework.*? I was tempted to think so, but then I looked<br>
at what's in there, and it's clearly facing the internals. Should it be<br>
in OpenSim.Region.Communications.*?<br>
OpenSim.Region.CoreModules.Communications.REST with sending and<br>
receiving parts as separate modules? (but then the importers of this<br>
will get all the other CoreModules as a dll, which doesn't feel right)<br>
<br>
Your thoughts appreciated. Just think of what makes sense from a program<br>
that wants to use OpenSim libraries.<br>
<br>
_______________________________________________<br>
Opensim-dev mailing list<br>
<a rel="nofollow" target="_blank" href="mailto:Opensim-dev@lists.berlios.de">Opensim-dev@lists.berlios.de</a><br>
<a rel="nofollow" target="_blank" href="https://lists.berlios.de/mailman/listinfo/opensim-dev">https://lists.berlios.de/mailman/listinfo/opensim-dev</a><br>
</blockquote>
</div>
<br>
<pre><hr size="4" width="90%"><br>_______________________________________________<br>Opensim-dev mailing list<br><a rel="nofollow" class="moz-txt-link-abbreviated" target="_blank" href="mailto:Opensim-dev@lists.berlios.de">Opensim-dev@lists.berlios.de</a><br><a rel="nofollow" class="moz-txt-link-freetext" target="_blank" href="https://lists.berlios.de/mailman/listinfo/opensim-dev">https://lists.berlios.de/mailman/listinfo/opensim-dev</a><br> </pre>
</blockquote>
<br>
<pre><hr size="4" width="90%"><br>_______________________________________________<br>Opensim-dev mailing list<br><a rel="nofollow" class="moz-txt-link-abbreviated" target="_blank" href="mailto:Opensim-dev@lists.berlios.de">Opensim-dev@lists.berlios.de</a><br><a rel="nofollow" class="moz-txt-link-freetext" target="_blank" href="https://lists.berlios.de/mailman/listinfo/opensim-dev">https://lists.berlios.de/mailman/listinfo/opensim-dev</a><br> </pre>
</blockquote>
<br>
</div><pre>_______________________________________________<br>Opensim-dev mailing list<br>Opensim-dev@lists.berlios.de<br>https://lists.berlios.de/mailman/listinfo/opensim-dev<br></pre></blockquote></td></tr></table><br>