[Opensim-dev] Comms Manager
Justin Clark-Casey
jjustincc at googlemail.com
Thu Feb 26 19:07:18 UTC 2009
MW wrote:
> I'm not actually bothered about the interface per se. What I require is
> to be able to dynamically load generic modules that no where in that
> module does it know about IScene/Scene.
>
> I actually see your approach as complex because it demands they need to
> know how to register to a scene themselves when these types shouldn't
> need to know. The types of modules I mean are ones where they just want
> to register with the Core/Application and be accessed from anywhere in
> the application.
>
> Of course this module type doesn't fit all needs, but thats what I'm
> saying its not right to try to find a single solution that fits all
> needs and turns out to be more complex than some modules require. And we
> shouldn't rule out such generic modules.
>
> Now we could still do meet the above requirement with you system, but it
> would mean doing some automagic in a ApplicationPlugin (or whatever
> interface they used) loader.
>
> As the loader would have to provide its own IServiceCore implementation,
> that it passed to the IServiceModules that it loaded, then it would need
> to as your examples show handle scene creation and register the all the
> IServiceModules with those.
>
> This it does get complex, where the simply solution and the one I favour
> is to just have a sharedRegistry that scenes can access. The whole
> automagic came from me trying to find a compromise that met your ideas.
> I really dislike it though, but we just need to find a compromise as we
> both have slighly different ideas and requirements.
>
> Thats why I would like to hear from other people.
Okay, it seems to me that the chief problem now is that MW would like to exposed service module methods to regions
without having to put any IScene methods in the module code, allowing it to be used for both the region server and grid
servers.
This is possible if all the service methods are exposed to the region. However, Melanie doesn't like this because it
will expose some methods that regions should arguably not be able to get at (such as
IInventoryService.CreateNewUserInventory()).
I would tend to think that we shouldn't expose such service methods to regions.
Neither side likes automagic by the core code, but I think a little bit of it will help here. Instead of having methods
such as
void RegisterInterfaceToAllRegistries<T>(T iface);
we instead annotate service modules with [RegionModule] and region interfaces with [RegionInterface]. Grid modules
which can also provide region services are annotated in this way. When the core code goes to load them, the
[RegionInterface] tagged interfaces are automatically registered with the region registry. This replaces
RegisterModuleInterface().
It also requires that IServiceModule and IRegionModule are collapsed together, by removing the IScene references in
IRegionModule. Instead, these are passed in via the OnNewScene() event talked about earlier.
In this way, service/application modules that aren't interested in scenes don't need to do any extra work apart from
tagging the module/interfaces appropriately, avoiding the boilerplate of separately registering the interface to each
region. The regions still don't have access to inter-service/non-region interfaces.
This does require a separate service registry hidden from the Region/Scene so that services can communicate among
themselves (e.g. the user service needs to call the inventory service to create new user inventories). There would be 2
registries in total.
Please excuse me if I haven't fully grokked all the previous posts on this thread.
>
> --- On *Thu, 26/2/09, Melanie /<melanie at t-data.com>/* wrote:
>
> From: Melanie <melanie at t-data.com>
> Subject: Re: [Opensim-dev] Comms Manager
> To: michaelwri22 at yahoo.co.uk, opensim-dev at lists.berlios.de
> Date: Thursday, 26 February, 2009, 5:28 PM
>
> I'm not objecting to your module. if IGridServiceCore then has the
> registry, then that is fone. I'm not dead set on IApplicationModule,
> it is simply the only one I know at that level.
>
> So, define:
>
> IGridServiceCore
> {
> ...
> void RegisterModuleInterface<T>(T module);
> void UnregisterModuleInterface<T>();
> T RequesModuleInterface<T>();
> ...
> }
>
> and the make IRegionLoader be one of those interfaces, and have
>
> IRegionLoader
> {
> ...
> event NewScene OnNewScene;
> event RemoveScene OnRemoveScene;
> ...
> }
>
> so you can use:
>
> PostInitialise()
> {
> IRegionLoader loader = core.RequestModuleInterface<IRegionLoader>();
> loader.OnNewScene += NewScene;
> }
>
> private void NewScene(IScene scene)
> {
> }
>
> and that
> will solve it.
>
> I am objecting only to the attempts to create a complex solution for
> a simple problem, when the above is the simple solution we already
> mostly have.
>
> Melanie
>
> MW wrote:
> > Well I still want to be able to have a module that implements a very
> simple generic interface something like:
> >
> > public interface IGridServiceModule
> > {
> > void Close();
> > void Initialise(IGridServiceCore core);
> > void PostInitialise();
> > }
> >
> > And all it has to do is call a register function on IGridServiceCore that
> makes it available to the application and scene. I don't want to have to
> have a separate IApplicationPlugin wrapper around all these modules. But I guess
> we could do some "hacking" in a IApplicationPlugin based module loader
> (for these IGridServiceModule types). Its just not very clean to have to do
> extra trickery in a
> loader to be able to load and register modules that
> don't need to have references to IScene.
> >
> > --- On Thu, 26/2/09, Melanie <melanie at t-data.com> wrote:
> > From: Melanie <melanie at t-data.com>
> > Subject: Re: [Opensim-dev] Comms Manager
> > To: michaelwri22 at yahoo.co.uk, opensim-dev at lists.berlios.de
> > Date: Thursday, 26 February, 2009, 5:05 PM
> >
> > In my (much simpler) design, the IScene won't even need to be on the
> > interface. All that is needed is for the core (Scene loader) to provide
> the
> > OnNewScene and OnRemoveScene events. In my example, I placed those on the
> > interface, that was actually not needed at all.
> >
> > I do believe that the registration to scenes should be done by a piece of
> > boilerplate code int he module itself, and not automagically. The
> automagical
> > registration leaves no room to expose a _different_ interface to the
> scene
> from
> > what is exposed to the application. Since many application level methods
> would
> > be useless to Scenes and may be harmful, and vice versa, the two-interface
> > approach I outlined seems cleaner.
> >
> > In the simplest case:
> >
> > MyApplicationModule : IApplicationPlugin
> > {
> > IApplicationPlugin members
> > ....
> > }
> >
> > Nothing special there, clean and simple
> >
> > Then, if we want to be notified about scenes to register to them, grab the
> > region loader interface:
> >
> > IRegionLoader loader =
> > application.RequestModuleInterface<IRegionLoader>();
> >
> > and _then_ hook from there:
> >
> > loader.OnNewScene += OnNewSceneHandler
> >
> > Which doesn't have to be on any interface.
> > It would just be a class member:
> >
> > private void OnNewSceneHandler(IScene scene)
> > {
> >
> }
> >
> > and that could then call the interface registration method
> >
> > That is clean, doesn't push Scenes into modules that don't want
> them,
> > allows exposing interfaces to Scenes with a minimum of boilerplate, and
> has no
> > automagic that is hard to understand or brittle.
> >
> > Melanie
> >
> >
> > MW wrote:
> >> I still think we should have a SharedRegistry that all Scenes have
> access
> > to. Some of the current shared RegionModules could move to using it as
> well. And
> > I know some of the other devs want one to; Adam and Stefan were talking
> about
> > one in IRC the other day.
> >>
> >> But if we all agree that we actually don't want one of them. Then
> a
> > possible compromise might be adding a extra RegisterToAllRegistries method
> to
> > the core Global registry interface so something like:
> >>
> >> public
> interface IGridServiceCore
> >> {
> >> T Get<T>();
> >> void RegisterInterface<T>(T iface);
> >> void RegisterInterfaceToAllRegistries<T>(T iface);
> >> bool TryGet<T>(out T iface);
> >> }
> >>
> >> This would add the interface to a list, that then is
> "copied" to
> > each region that starts up, so a kind of auto registration. Without the
> modules
> > having to be given scene references if the interface type they are using
> > doesn't support that.
> >> So all we would be doing is making OpenSimBase implement that
> interface
> > and provide the support for the "auto registration" to Scenes
> with
> > RegisterInterfaceToAllRegistries. Any module/plugin using
> RegisterInterface
> > would only register with the Global/Application registry that wouldn't
> be
> > accessable from regions.
> Of course they could then manually register
> themselves
> > with the regions.
> >>
> >> I just really dislike trying Scene/IScene into all the plugin
> interfaces.
> > I'm fine with plugins being able to access them via a
> IApplicationPlugin if
> > thats the way the plugin creator did things. But I also want a more
> generic
> > module type that can still offer services to regions/scenes. Most likely
> using
> > the plugin loader approach I mentioned earlier. If this extra plugin
> loading was
> > done by a ApplicationPlugin then anyone who didn't want to support
> those
> > types could easily remove that loader.
> >>
> >> --- On Thu, 26/2/09, Melanie <melanie at t-data.com> wrote:
> >> From: Melanie <melanie at t-data.com>
> >> Subject: Re: [Opensim-dev] Comms Manager
> >> To: michaelwri22 at yahoo.co.uk, opensim-dev at lists.berlios.de
> >> Date: Thursday,
> 26 February, 2009, 2:40 PM
> >>
> >> I think that would introduce a layer of complexity in core, where i
> think
> > that
> >> complexity (e.g. registering to scenes) s better off distributed
> inside
> > the
> >> modules that actually need it. Keep it simple. I believe my approach
> is
> > what
> >> will work with the least amount of core code, and provide the greatest
> >> flexibility.
> >>
> >> Melanie
> >>
> >> MW wrote:
> >>> I know I said we should wait for other people to give some input,
> but
> > just
> >> one last suggestion.
> >>>
> >>> Maybe we should have three registeries. A
> ApplicationServiceRegistry
> > that
> >> is only accessable from the application level), A
> SharedServiceRegistry
> > that is
> >> accessable from the application and all scenes/regions. And then the
> >
> current
> >> Registry in Scene.
> >>>
> >>> Then its upto the modules/components/plugins to which registries
> they
> > want
> >> to register.
> >>>
> >>> And certain plugin types might only get references allowing them
> to
> >> register to certain registeries.
> >>> --- On Thu, 26/2/09, MW <michaelwri22 at yahoo.co.uk> wrote:
> >>> From: MW <michaelwri22 at yahoo.co.uk>
> >>> Subject: Re: [Opensim-dev] Comms Manager
> >>> To: opensim-dev at lists.berlios.de
> >>> Date: Thursday, 26 February, 2009, 1:48 PM
> >>>
> >>> Well actually my suggestion of supporting multiple plugin
> interfaces
> >> allowed both approaches and left everything up to the module creator.
> >>> But I think we should wait for input from others now as we
> aren't
> >> really getting anywhere on the fine details. I
> think we have the basis
> of
> > a
> >> system just need to get other peope's input so we can work out
> those
> > small
> >> details. Like the main one being should the global registry be
> accessable
> > from
> >> regions. And if we decide it shouldn't, is it okay for it be in
> the
> > short
> >> term so we can refactor comms manager easiest. ie comms manager
> becomes
> > the
> >> global registry for now.
> >>> --- On Thu, 26/2/09, Melanie <melanie at t-data.com> wrote:
> >>> From: Melanie <melanie at t-data.com>
> >>> Subject: Re:
> >>> [Opensim-dev] Comms Manager
> >>> To: michaelwri22 at yahoo.co.uk, opensim-dev at lists.berlios.de
> >>> Date: Thursday, 26 February, 2009, 1:36 PM
> >>>
> >>> If you want to be more flexible, then my approach is better. In
> your
> >> model, a global module has not
> way to _prevent_ being accessed by
> Scene.
> >>>
> >>> I believe Scene has no business holding a ref to the application,
> or
> >> accessing the global registry.
> >>>
> >>> In my design, each module has the power to decide whether it wants
> to
> > be
> >> accessible from Scene and what methods it exposes to it. Your method
> > reduces
> >> that duality into a single interface and makes all scenes be able to
> > access all
> >> methods on all interfaces. That leaves no room for isolation, even if
> a
> > module
> >> writer would want it.
> >>>
> >>> I believe the modules _should_ indeed register with each scene in
> a
> >> callback, and that would actually let them register only to specific
> > scenes if
> >> they wanted to. More flexibility
> >>> yet.
> >>>
> >>>
> Melanie
> >>>
> >>> MW wrote:
> >>>> Hmm, I never suggested anything that would mean one scene be
> able
> > to
> >>> directly access another.
> >>>>
> >>>> I see the GlobalRegistry as a very basic interface something
> like:
> >>>>
> >>>> public interface IGridServiceCore
> >>>> {
> >>>> T Get<T>();
> >>>> void RegisterInterface<T>(T iface);
> >>>> bool TryGet<T>(out T iface);
> >>>> }
> >>>>
> >>>> [Which would be in OpenSim.Framework or wherever]
> >>>>
> >>>> So if we did want a Scene to be able to access it, all it
> would
> > need
> >> on
> >>> creation is pass a IGridServiceCore reference in its parameters.
> So it
> >>> doesn't actually change
> anything compared to how things are
> now
> > with
> >> the
> >>> shared modules.
> >>>>
> >>>> I just am still not sure that GlobalServices should have to
> >> indivudally
> >>> register with the Scenes even if they want to provide services to
> > region
> >>> modules. I see the
> >>> module that handled User server comms as a global service but
> >>> don't think it should have to register with all regions.
> I'm
> > more
> >> in
> >>> mind that it should just register with the global registry and
> then
> > region
> >>> modules than access that.
> >>>>
> >>>> And yes nothing I have suggested stops a ApplicationModule and
> a
> >>> RegionModule from sharing a dll, and the ApplicationModule starts
> up
> > and
> >>> registers the RegionModule or whatever. I just
> don't think its
> the
> >> solution
> >>> for everything. So am trying to think of way of being more
> flexible.
> >>>>
> >>>>
> >>>> --- On Thu, 26/2/09, Melanie <melanie at t-data.com> wrote:
> >>>> From: Melanie <melanie at t-data.com>
> >>>> Subject: Re: [Opensim-dev] Comms Manager
> >>>> To: michaelwri22 at yahoo.co.uk, opensim-dev at lists.berlios.de
> >>>> Date: Thursday, 26 February, 2009, 1:14 PM
> >>>>
> >>>> Hi,
> >>>>
> >>>> one of the paradigms is that no Scene should directly access
> > another
> >>>
> >>>> Scene.
> >>>>
> >>>> Therefore, providing a clear path to the global registry from
> the
> > DLL
> >> Scene is in would break that isolation.
> >>>>
> >>>> Really, global modules
> that want/need to be accessed from
> Scene
> > can
> >> register an interface there.
> >>>> Also, processing will probably need to be broken up into a
> part
> > that
> >> has the Scene type and a part that doesn't.
> >>>>
> >>>> This is where I think a global module and a region module as
> well
> > as
> >> the interfaces used between them can share a dll.
> >>>>
> >>>> The global module would register that interface on the region,
> and
> > the
> >> region modules uses it.
> >>>>
> >>>> That is much cleaner.
> >>>>
> >>>> Melanie
> >>>>
> >>>> MW wrote:
> >>>>> Well I hadn't really thought out all the details but
> what
> > I
> >> meant
> >>> is
> >>>> we
> >>>>> can have a IApplicationPlugin
> that can load other plugin
> types
> >> itself.
> >>>
> >>>>>
> >>>
> >>>>>
> >>>>>
> >>>>> So if we look at the code in OpenSimBase that loads
> >>> IApplicationplugins it
> >>>> is:
> >>>>>
> >>>>>
> >>>>>
> >>>>> protected virtual void LoadPlugins()
> >>>>>
> >>>>> {
> >>>>>
> >>>>> PluginLoader<IApplicationPlugin> loader
> =
> >>>>>
> >>>>> new
> PluginLoader<IApplicationPlugin>(new
> >>>> ApplicationPluginInitialiser(this));
> >>>>>
> >>>>>
> >>>>>
> >>>>> loader.Load("/OpenSim/Startup");
> >>>>>
>
> >>>>> m_plugins = loader.Plugins;
> >>>>>
> >>>>> }
> >>>>>
> >>>>>
> >>>>>
> >>>>> and the plugin initialiser is :
> >>>>>
> >>>>>
> >>>>>
> >>>>> public class ApplicationPluginInitialiser :
> >> PluginInitialiserBase
> >>>>>
> >>>>> {
> >>>>>
> >>>>> private OpenSimBase
> >>> server;
> >>>>>
> >>>>> public ApplicationPluginInitialiser (OpenSimBase
> s) {
> >> server =
> >>> s;
> >>>> }
> >>>>>
> >>>>> public override void Initialise (IPlugin plugin)
> >>>>>
> >>>>> {
> >>>>>
>
> >>>>> IApplicationPlugin p = plugin as
> > IApplicationPlugin;
> >>>>>
> >>>>> p.Initialise (server);
> >>>>>
> >>>>> }
> >>>>>
> >>>>> }
> >>>>>
> >>>>>
> >>>>>
> >>>>> so there is no reason why inside a ApplicationPlugin we
> > can't
> >> do
> >>>> something like:
> >>>>>
> >>>>>
> >>>>>
> >>>>> public void Initialise(OpenSimBase openSim)
> >>>>>
> >>>>> {
> >>>>>
> >>>>> LoadGridServiceModules(openSim);
> >>>>>
> >>>>> }
> >>>>>
> >>>>>
> >>>>>
> >>>>> Protected
> virtual void LoadGridServiceModules(OpenSimBase
> >> openSimBase)
> >>>>>
> >>>>>
> >>>
> >>>>>
> >>>>> {
> >>>>>
> >>>>>
> >>>>>
> >>>>> PluginLoader<IGridServiceModule> loader
> =
> >>>>>
> >>>>>
> >>>>>
> >>>>> new
> PluginLoader<IGridServiceModule>(new
> >>>> GridServicePluginInitialiser(openSimBase.GlobalRegistry));
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>> loader.Load("/OpenSim/GridService");
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> m_plugins = loader.Plugins;
> >>>>>
> >>>>>
> >>>>>
> >>>>> }
> >>>>>
> >>>>>
> >>>>>
> >>>>> public class GridServicePluginInitialiser :
> >> PluginInitialiserBase
> >>>>>
> >>>>> {
> >>>>>
> >>>>> private IGridServiceCore m_core;
> >>>>>
> >>>>> public ApplicationPluginInitialiser (IGridService
> > core) {
> >>> m_core =
> >>>> core;
> >>> }
> >>>>>
> >>>>> public override void Initialise (IPlugin plugin)
> >>>>>
> >>>>> {
> >>>>>
> >>>>> IGridServiceModule p = plugin as
> > IGridServiceModule;
> >>>>>
>
> >>>>> p.Initialise (m_core);
> >>>>>
> >>>>> }
> >>>>>
> >>>>> }
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>> So its then loaded the IGridServiceModules and passed them
> > only a
> >>>> reference to the GlobalRegistry (from OpenSimBase).
> >>>>>
> >>>>>
> >>>>>
> >>>>> And for plugins/modules that want to register with scenes,
> we
> >> could
> >>>>> either have another plugin type and loader, or just use
> >>>>> IApplicationPlugin directly for them.
> >>>>>
> >>>>>
> >>>>>
> >>>>> Of course this opens up the question if at any point the
> >>>
> GlobalRegistry
> >>>>> should be accessable from scenes. If we are going to go
> with
> >>> the
> >>>>> approach that modules that should be accessable from
> scenes
> > should
> >>>>> register with them then I guess the answer is no. But I
> can
> > see
> >> people
> >>>>> wanting to be able to access the GlobalRegistry from
> Region
> >> modules
> >>> and
> >>>>> trying to do hacks so they can.
> >>>>>
> >>>>> --- On Thu, 26/2/09, Melanie <melanie at t-data.com>
> wrote:
> >>>>> From: Melanie <melanie at t-data.com>
> >>>>> Subject: Re: [Opensim-dev] Comms Manager
> >>>>> To: michaelwri22 at yahoo.co.uk, opensim-dev at lists.berlios.de
> >>>>> Date: Thursday, 26 February, 2009, 12:50 PM
> >>>>>
>
> >>>>> I'd have to see that, but it sounds good.
> >>>>>
> >>>>> Can you illustrate?
> >>>>>
> >>>>> Melanie
> >>>>>
> >>>>> MW wrote:
> >>>>>> Just a though,t but maybe we are trying to be too
> generic
> > in
> >>> finding a
> >>>>> single interface that meets all needs. We have a plugin
> >>> loader
> >>>> (Mono.addins)
> >>>>> that can quite easily load different plugin types. So by
> using
> > the
> >>>>> IApplicationPlugin system, we can have them also loading
> other
> >> plugin
> >>>> types.
> >>>>>>
> >>>>>> If basically we are saying that we want two different
> >>> Module/Interface
> >>>>> registeries (Global and Scene), then there
> is no reason
> that
> > as
> >> long
> >>> as
> >>>> all the
> >>>>> plugins only register interfaces with those registeries
> why we
> >>> can't
> >>>> have
> >>>>> the multiple plugin types. So we have a type (and loader)
> that
> > is
> >> able
> >>> to
> >>>>> register event handlers so it can be informed about
> scenes.
> > And we
> >> a
> >>>> loader that
> >>>>> can load the modules from the Grid servers directly.
> >>>>>>
> >>>>>> The loaders would be minor things basically just using
> >>> PluginLoader to
> >>>>> load the plugins.
> >>>>>>
> >>>>>> We could say this increases
> >>> the complexity, but I actually think
> >>> by
> >>>>
> having
> >>>>> initialisation interfaces that are right for the task that
> the
> >> modules
> >>> are
> >>>> going
> >>>>> to do makes sense.
> >>>>>>
> >>>>>> --- On Thu, 26/2/09, Melanie
> <melanie at t-data.com>
> > wrote:
> >>>>>> From: Melanie <melanie at t-data.com>
> >>>>>> Subject: Re: [Opensim-dev] Comms Manager
> >>>>>> To: opensim-dev at lists.berlios.de
> >>>>>> Date: Thursday, 26 February, 2009, 12:36 PM
> >>>>>>
> >>>>>> I don't think Grid and Asset modules need to load
> into
> >> region servers, and vice versa. At least not by the same interface.
> That
> >> interchangeability makes other things that are useful almost
> impossibly
> > complex.
> >>>>>>
>
> >>>>>> Melanie
> >>>>>>
> >>>>>> Stefan Andersson wrote:
> >>>>>>> No, didn't notice that, but I question why
> >>> Grid or Asset
> >>>> server
> >>>>>> modules should even be aware of that, regardless of
> how
> > the
> >> IScene
> >>>>> interface
> >>>>>> looks or what types that, in turn, pulls in.
> >>>>>>>
> >>>>>>> Best regards,
> >>>>>>> Stefan Andersson
> >>>>>>> Tribal Media AB
> >>>>>>>
> >>>>>>>
> >>>>>>>> Date: Thu, 26 Feb 2009 12:29:19 +0000
> >>>>>>>> From: melanie at t-data.com
> >>>>>>>> To: opensim-dev at lists.berlios.de
> >>>>>>>> Subject:
> Re: [Opensim-dev] Comms Manager
> >>>>>>>>
> >>>>>>>> Hi,
> >>>>>>>>
> >>>>>>>> note that I used IScene sxclusively?
> >>>>>>>>
> >>>>>>>> Melanie
> >>>>>>>>
> >>>>>>>> Stefan Andersson wrote:
> >>>>>>>> > Um, yeah, having 'Scene' as a
> type in
> >>> anyhting
> >>>>> outside
> >>> of
> >>>>>> the Region will lead to grief.
> >>>>>>>> > > > Suggestion:
> >>>>>>>> > > > > --- OpenSim.Framework: ---
> >>>>>>>> > > > > IGenericModule
> >>>>>>>> > > {
> >>>>>>>> > >
> Initialise();
> >>>>>>>> > > PostInitialise();
> >>>>>>>> > > }
> >>>>>>>> > > > > ---
> OpenSim.Region.Framework:
> > ---
> >>>>>>>> > > >
> >>>
> >>>>>>>> > IRegionModule : IGenericModule
> >>>>>>>> > > {
> >>>>>>>> > > OnNewScene();
> >>>>>>>> > > OnSceneRemoved();
> >>>>>>>> > > }
> >>>>>>>> > > > > Best regards,
> >>>>>>>> > Stefan Andersson
> >>>>>>>> > Tribal Media AB
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>
>
> >>>
> > ------------------------------------------------------------------------
> >>>>>>>
> >>>>>>> _______________________________________________
> >>>>>>> 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
> >>>> _______________________________________________
> >>>> 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
> >>
> >>
> >>
> >>
> >>
> >>
> ------------------------------------------------------------------------
> >>
> >> _______________________________________________
> >> 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
--
justincc
Justin Clark-Casey
http://justincc.wordpress.com
More information about the Opensim-dev
mailing list