I guess your pulling out that code made the situation more explicit than
it was before :)
If that's the case, could we then think of separating the basic "Map
service" from any administrative grid services that people may want to
come up with for grids.
Running a grid a-la Linden Lab involves a lot of admin work that can
indeed, be automated by having config and admin information in a
centralized place -- URLs of servers, ban lists, etc etc etc., to be
shared among a group of regions.
But this is completely different from the Map service, which I see as a
fundamental "space" service in VWs, and that exists also for
standalones, Hypergrid, etc. and that can be made mix-and-match.
Something like this:
OpenSim.Servers.AssetInventoryServer
OpenSim.Servers.AssetServer
OpenSim.Servers.GridAdminServer
OpenSim.Servers.InventoryServer
OpenSim.Servers.MapServer
OpenSim.Servers.MessagingServer
OpenSim.Servers.RegionServer (What's now known as OpenSim.exe)
OpenSim.Servers.UserServer
Better yet would be to be able to configure blank-slate *servers*
running a payload of any combination of *services*. Would that be possible?
So then we would have
OpenSim.GenericServicesServer
OpenSim.RegionServer
Where the generic server would be configured via dll specification, or
any other module system. This would, hopefully, improve the current
situation of having both two separate inv and asset servers, and a
third server which is a combination of those two. And it would give
people more options for configuring their worlds according to their own
expected usage.
And, going all the way, we might end up with just one single
GenericServer, which, when configured with running all services, would
be the equivalent of the standalone mode.
Probably not something that can be done overnight, but just a thought...
MW wrote:
Well the name changed came from because at first I was doing a
different ICore interface for each server. So had IGridCore,
IUserCore, IMessagingCore (not all committed to SVN). But then wanted
a common core interface. And as IGridCore gave the impression that it
was for the Grid server, I went with IUGAIMCore, but it was only meant
to be temporary. I don't care what we call that. And agree IUGAIMCore
isn't the right long term name.
As for messaging in the grid server, thats where messaging servers
register with the grid server, so that when regions login to the grid
server, it can provide them with the details of the messaging servers.
That isn't anything new, all I did was split those functions into
their own "module".
Maybe a name change on that module is needed as well, so its clear its
about Messaging servers registering with it and provides a inteface so
other modules can register the data about those registered messaging
servers.
--- On *Mon, 23/2/09, Diva Canto /<[email protected]>/* wrote:
From: Diva Canto <[email protected]>
Subject: Re: [Opensim-dev] Grid vs UGAIM (WAS: Re:
[Opensim-commits] r8554 - trunk/OpenSim/Grid/GridServer)
To: [email protected]
Date: Monday, 23 February, 2009, 1:44 AM
I think I understand where the name change comes from, but this
leads to a deeper question: why is there anything Messaging in the
Grid service? And is there any intention of adding more service
registrations there?
Crista
Mike Mazur wrote:
Hi,
On Sat, Feb 21 2009 10:41:28 -0800
[email protected] wrote:
Author: mw
Date: 2009-02-21 10:41:28 -0800 (Sat, 21 Feb 2009)
New Revision: 8554
Added:
trunk/OpenSim/Grid/GridServer/IUGAIMCore.cs
Removed:
trunk/OpenSim/Grid/GridServer/IGridCore.cs
To me the general term "Grid" makes more sense, as it doesn't hardcode
the current set of servers that constitute a grid in the source code.
What happens when we add a new server to the grid setup (ie: script
server)? When the acronym changes, will the filename/interface
name/class name be updated?
Thanks,
Mike
_______________________________________________
Opensim-dev mailing list
[email protected]
https://lists.berlios.de/mailman/listinfo/opensim-dev
_______________________________________________
Opensim-dev mailing list
[email protected]
https://lists.berlios.de/mailman/listinfo/opensim-dev
------------------------------------------------------------------------
_______________________________________________
Opensim-dev mailing list
[email protected]
https://lists.berlios.de/mailman/listinfo/opensim-dev
_______________________________________________
Opensim-dev mailing list
[email protected]
https://lists.berlios.de/mailman/listinfo/opensim-dev
