I would definitively think that the Region Modules wuld get a ref to the global
services registry.
I totally agree with your sentiment, but I also see that you have to draw a
line somewhere. This is going to sound odd coming from me, but you need to take
SOME design decisions, even in a
Well I agree the name CommsManager is a bad choice and I'm all for
changing/getting rid of that. I don't see this as a Manager but just another
registery of modules. My proposal certainly isn't about making/keeping all the
comms code centralised. I totally agree that we should have modules, and
PS. One issue that I don't like about a lot of the Region to UGAIM code that
is currently in some of the region modules, is how the network/transport code
is mixed up with the handling of some basic features like friends, presences
etc. I do think we should have separate transport modules.
So
I think that's what Melanie is leaning towards, but that would mean every
module would have to be connected to at least one scene.
I do believe that you would have modules doing stuff already from a setting
where there is no scenes loaded.
The regionLoader, for example. :D
Best regards,
I think that is basically what me and Stefan are talking about. I started off
with the modules being more specialised for network/comms (and db in standalone
mode), but from the discussions the idea is basically morphing into a Global
module system.
--- On Thu, 26/2/09, Frisby, Adam
I was never suggesting that we keep CommsManager as it is. I was suggesting
baby steps so for now there would be a commsManager, but inside it, it would be
broken up into modules, that just registered interfaces. Then in time we would
get rid of the current CommsManager interface and just have
Well, I wanted to remove that extra step in the global namespace chain.
The idea was not to supply any Scenes to these modules as a part of
startup, rather like this chain of events:
MyApplicationModule : IMyApplicationModule, IMyRegionModuleInterface
MyApplicationModule.Initialise(Application
+1, looks good.
Best regards,
Stefan Andersson
Tribal Media AB
Date: Thu, 26 Feb 2009 11:38:52 +
From: mela...@t-data.com
To: michaelwr...@yahoo.co.uk; opensim-dev@lists.berlios.de
Subject: Re: [Opensim-dev] Comms Manager
Well, I wanted to remove that extra step in the global
I'm actually with Melanie on this; using the call-back registration and event
attachment seems so much flexible and cleaner - and more in line with where the
region modules have been taking us.
Best regards,
Stefan Andersson
Tribal Media AB
Date: Thu, 26 Feb 2009 11:56:31 +
From:
And, as an afterthought:
IClientTrackerModule
{
OnNewClient(IScene scene, IClientCore client);
OnClientClose(IScene scene, IClientCore client);
}
IClientTracker : IGlobalModule, IClientTrackerModule
Initialise()
{
OnNewScene += OnNewScene;
OnRemoveScene += OnRemoveScene;
}
OnNewScene(IScene
Well I think we are very close to having a combined solution/proposal.
The two differences I see between my proposal and melanie's are the
initialisation interface for the modules and where they can register their own
interfaces with.
For initialisation we have two different interfaces(that
I still question if Global modules (that are really providing global services)
should get any references to Scene/IScene; either by events of initialisation
calls. If they are providing services, then other modules/components should be
consumers of them, so only the consumers need references to
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();
Hi,
Scenes _will_ be handled there, so, it might as well be facilitated,
rather than attempting an isolation level that won't work in
practice, leading to horribly ugly hacks to circumvent it later.
I have lined out 3 concrete use cases (ClientTracker, SceneTracker,
RemoteAdmin) already that
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
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.
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
You just can't let go of the centralistic *Manager idea..!
IMHO, clients have no business at app level. Clients connect to
regions through client stacks. Which can be shared modules for
constellations where one client connection handles all regions in an
instance.
IGlobalModuleRegistry
{
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()
{
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 GetT();
void RegisterInterfaceT(T iface);
bool TryGetT(out T
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
We also should think of baby steps in how we could refactor the current setup.
We do have the CommsManager if we like it or not, and I do think the easiest
way to refactor that is to make it into a global Registry that can be accessed
from the regions.
That requires the least amount of work
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
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
I think introducing cruft to fix cruft is no good.
I think that the new system should be brought in alongside the old
as a clean start, and then services migrated to it, rather than
trying to morph CommsManager.
Melanie
MW wrote:
We also should think of baby steps in how we could refactor
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
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
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
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
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 RegisterModuleInterfaceT(T module);
void UnregisterModuleInterfaceT();
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
Well, here goes
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.
That can be done with what you suggested
I actually see your approach as
Again your looking for one solution where I don't think one fits or if it does
we haven't found it. I don't see RegionLoaders or anything like that using the
generic interface that I'm talking about. They should be separate and as you
said the scene shouldn't have access to them.
But that
A couple of issues/questions are:
How would a
Region/ServiceModule say what interface it wanted to register, it might
implement a couple but only want to register one, or it might want to
register its class type.
And I'm taking it we would still have
the ApplicationPlugin that could register
[Warning: long and heavy-duty stuff here]
So, I just had an insight this morning as I woke up. We've scratched our
heads about this fuzzy black-box component called the viewer, and how
horrible it is for open systems because it assumes the regions proxy all
the security-critical data etc etc.
MW wrote:
A couple of issues/questions are:
How would a Region/ServiceModule say what interface it wanted to
register, it might implement a couple but only want to register one, or
it might want to register its class type.
:( Yeah, you're right - for some reason I forgot that you have to
Justin Clark-Casey wrote:
Another critical example: inventory. The CAP URL for this should be
pointing directly to the Inventory server, not to the regions. I
understand that inventory over CAPs had some issues in the past. I just
fiddled with it this morning, and it's working -- I'm sure
Here's the thing: the CAPs giver can define whatever it wants as CAPs
providers. So I think what we have currently is a subset of what I'm
saying below. Specifically, the CAPs giver can delegate CAPs to trusted
regions.
But obviously, we need to think more about this. My main goal here is to
Melanie wrote:
Linden turned it off because it's broken in the client. So, we can
try to use it but will hit the same wall, since the client was never
fixed.
Melanie: are you 100% sure about this? This, of course, is critical. The
whole point of my thinking was to access inventory over
That is what was said. Linden reverted the inventory protocol to UDP
on their servers because of an issue in the viewer that was so
fundamental that it was decided to not be worth fixing.
Whether this is true, I don't know. but it was said.
Melanie
Diva Canto wrote:
Melanie wrote:
Linden
I don't subscribe to that mailing list. Can someone please do that?
I've been searching on Google, and I found a meeting with Mark where he
clearly says that inventory access has swicthed to caps:
http://wiki.secondlife.com/wiki/User:Zero_Linden/Office_Hours/2008_Mar_13
(search 'caps')
I
I can do that.
Is the correct question:
Are the inventory requests done via caps or via UDP?
Von: opensim-dev-boun...@lists.berlios.de
[mailto:opensim-dev-boun...@lists.berlios.de] Im Auftrag von Diva Canto
Gesendet: Donnerstag, 26. Februar 2009 22:24
An: opensim-dev@lists.berlios.de
Yes, something like that.
And If they're done via UDP, what was the problem with the Inventory
CAP that was deployed sometime last year?
Thanks.
Dirk Krause wrote:
I can do that.
Is the correct question:
Are the inventory requests done via caps or via UDP?
*Von:*
Done.
Von: opensim-dev-boun...@lists.berlios.de
[mailto:opensim-dev-boun...@lists.berlios.de] Im Auftrag von Diva Canto
Gesendet: Donnerstag, 26. Februar 2009 22:32
An: opensim-dev@lists.berlios.de
Betreff: Re: [Opensim-dev] Authentication, take 2: Capabilities
Yes, something like that.
Currently, we have three projects, the test client and two NPC
demos, that are essentially unmaintained.
I would propose to drop those from core, since their only reason for
existence seems to be to increase the count of files to edit when
adding to IClientAPI.
Dropping those from core would
Melanie wrote:
Currently, we have three projects, the test client and two NPC
demos, that are essentially unmaintained.
I would propose to drop those from core, since their only reason for
existence seems to be to increase the count of files to edit when
adding to IClientAPI.
I'm not
On that subject I keep coming back to the idea that there should be two
register Interface methods.
And my lastest idea is about having the concept of Primary Registry and
Secondary Registry as a concept in the IServiceCore interface.
The primary registry will be the protected Application
Or a slightly different approach would be to add a security level as a a param
of the RegisterInterface method.
So that a module could register multiple interface with different security
levels. Its then up to the application/loader which componets get access to
which interfaces (or in our
Why is it that you want to have some fixed, hardcoded behavior
instead of leaving it to the module?
I thought what we ended up with was fine and agreeable to all, and
now here you come again with region modules/regions accessing the
core directly. I think that is a BadIdea(tm) to allow calls
Did you actually read what I said? I said the base idea of
ApplicationPlugins being able to register with the ApplicationRegistry
and with scenes as they wish is what we were going with. But we would
then have a Plugin that was a loader of IServiceModules.
The ideas I was throwing out there
Hi,
MW wrote:
Again I never mentioned the Regions/Region modules accessing the core
at all. I said the Service modules would be able to use diferent
Registry methods to say if they should be added to the Scene Registries
or not. I'd say thats a step away from a hardcode behavior of having
After more poking at the viewer, here's what I found.
FetchInventoryDescendents seems to be working consistently over CAPs, in
fact better than over UDP. When the agent logs in, the client always
invokes that CAP, unlike the message over UDP which only seems to come
after a clear cache. That
Well, if FetchInventoryDescendents works better over CAPS, then we
can try using that. Now, that would serve another purpose beyond
your intended trust issue:
Currently, inventory is fetched by the region en-bloc, rather than
being fetched only on demand. There isn't even a function to fetch a
daniel miller kirjoitti:
sorry for the cross-post, but this is something I think all parties
yah wasn't sure where to reply, but doesn't matter too much i guess :o
should be aware of. I have been asked to give a short presentation
plus QA on Opensim, Openviewer, and RealXtend (focus on
54 matches
Mail list logo
