[Opensim-dev] Supplying IScene instead of Scene for the future region modules mechanism

Tue Apr 14 19:21:01 UTC 2009

> - Should core really limit what _can_ be done by non-core module coders?

Yes. And in what sequence, and in what ways. That is what programming is. That is what designing is. And it's how you help people understand the intended use of an API.

We've already done that in Scene. Some things are private, some are protected. Some functions take values as parameters, others use the internal state.

> - Is it very likely that anyone would make a new Scene-type object 
> without inheriting from Scene?

Yes, definitively. Mocking is the most immediate example, but I can definitively think of scenarios where the inner workings of the SceneGraph would work radically different. For example, if the administration of inner state should be different, optimized, or simply react in other ways - say, because a third-party external protocol is radically different. I can definitively see why you'd want a 'passive' scene that just worked as a data model, not even running updates or backups for example, while still being able to function in a live region, and work with other SceneGraph objects.

> I believe that passing Scene directly is the right thing to do, as 
> the region modules' functionality is largely tied to Scene in an 
> indissoluble way anyway.

Which is in itself part of the problem. The way concrete classes are tied together right now makes it a mess to encapsulate, re-define or unit test in any sensible manner.

> Any interface would just have to carry 
> almost all methods of Scene anyway, and add yet another file to edit 
> when adding fundamental functionality.

Which is why I was proposing one re-evaluate the Scene methods, one by one. Incidentally, if what you say is true, we have WAY too many public methods and properties on Scene.

> Also, I believe it is very unlikely that someone would not inherit 
> Scene since it provides a huge amount of the bery basic 
> functionality everyone needs. If someone doesn't inherit Scene, they 
> are doing something fundamentally different and existing region 
> modules would be of no use to them anyway.

The problem is rather it provides too much, and in a way that makes it impossible to disentangle for cases where you want to be able to work with the classes in other ways than as part of a living live region.

> I know such an IScene would break all my private region modules, and 
> probably everyone else's, unless I add a slew of methods and 
> properties to IScene to make them work again.

I don't think anybody, so far, has proposed to define what the supplied IScene would and would not contain. That is why I think there should be a serparation between what the core wants out of a IScene and what the region modules want.

And maybe the region should have _more_ available than the core should. I can definitively think of cases where the core would want to be able to run a scene that does not implement the full ISceneForRegionModules simply because there will be no region modules loaded for that scene.

> I believe we can't possibly anticipate every method that needs to be 
> accessed, and we should not limit it to what we think is "correct" 
> or "hygienic". After all, someone may not even want to tell us what 
> their region modules are for, therefore would not aubmit their patch 
> but keep it as a private patch, adding maintenance effort and 
> complicating things.

I say 'correct' and 'hygienic' purely from a state-encapsulating, and best-practise point of view. If we believe neither of these apply to the method under discussion, or if we're too lazy to help the implementer get a coherent picture of how the public and protected methods are supposed to interact, then we'll just not bother, add the method and move on.

> I believe that would not be in the spirit of the BSD licensing if we 
> were to say "you can do what you want with it, but we'll make it as 
> hard as we can".

Nobody has, as far as I can see, forwarded that sentiment. I think we must be both misunderstanding each other?

/Stefan

> Stefan Andersson wrote:
> > Justin, Homer;
> > 
> > 
> > 
> > consider two things you might:
> > 
> > 
> > 
> > 1) take the opportunity to take a moment to re-ponder each "missing" IScene power - should the caller perhaps move instead? Or should the called method move to a place where the caller has access without going thru IScene? Maybe the Scene is too big, not IScene too small?
> > 
> > 
> > 
> > 2) maybe the notion of a IScene vs a ISceneBase is really an indication that you should have a 'ISceneForRegionModules' instead - an facade enumerating the powers the core wish to expose to the scene, to force the region module coder to code in a hygienic way. Laying the foundations for a ISceneAPI, if you will?
> > 
> > On my mind for a long time, both these things has been.
> > 
> > 
> > Best regards,
> > Stefan Andersson
> > Tribal Media AB
> > 
> > 
> > 
> > 
> >> Date: Tue, 14 Apr 2009 18:02:45 +0100
> >> From: jjustincc at googlemail.com
> >> To: opensim-dev at lists.berlios.de
> >> Subject: [Opensim-dev] Supplying IScene instead of Scene for the future region modules mechanism
> >> 
> >> Hey Homer (since this is primarily addressed to you :),
> >> 
> >> I see you're making some progress on the up-and-coming new region modules mechanism.
> >> 
> >> Instead of passing Scene itself to region modules, could we create an interface so that we better control the amount of 
> >> innards that we expose to region modules? It's convenient-ish to give the original Scene class to modules now, but it 
> >> will cause us problems down the road.
> >> 
> >> I'm quite happy to pitch in with this if you want. I suggest renaming the existing IScene to ISceneBase (since that's 
> >> what it really is) and creating a new IScene that's implemented by Scene.
> >> 
> >> It strikes me that it's going to be more convenient to do this when we introduce the new system than as a separate change.
> >> 
> >> Thoughts?
> >> 
> >> -- 
> >> justincc
> >> Justin Clark-Casey
> >> http://justincc.wordpress.com
> >> _______________________________________________
> >> 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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://opensimulator.org/pipermail/opensim-dev/attachments/20090414/312f228c/attachment-0001.html>