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

Tue Apr 14 22:32:49 UTC 2009

This entire discussion is, of course, moving away from the thing 
that started it all.
The original plan was to make a region module API that is able to 
support dynamic loading and unloading of regions, then quickly 
convert all modules to that API.

If we now go into ISceneAPI and loads of refactoring, the very basic 
function of a single region restart will be delayed an indefinite 
amount of time, and since we then can't deprecate and remove the old 
interface quickly, it can't be depended on for a long time, since 
many modules just need Scene and will not be migrated.

Now, we think differently here.

I think that exposing a full class to region modules and accepting 
that region modules written for Scene will not work with MyNew 
Scene, but that will instead have it's own set of modules, unless it 
inherits from Scene, is less evil than even a single upcast of 
IScene to Scene. Upcasts are, in my eyes, the ultimate evil. I;d 
like to avoid the need for that and I see it becoming ubiquitous if 
this ISceneAPI is implemented.

Melanie

Teravus Ovares wrote:
> I have some great ideas for region modules...     and..    I don't
> have the time to do them over and over again when the API changes AND
> work on OpenSimulator too.
> 
> This has been one of my 'showstopper' reasons for not working on some
> region module ideas that I have.
> 
> So, if we're going with an interface..   We need to commit to the
> interface, whatever it is..  and keep API within the interface the
> same after some amount of experimentation.    I personally, consider
> the definition of an Interface, the 'mark' that things within the
> interface are going to stay mostly the same.   If they change, it
> warrants a release notes update and maybe a mailing list post warning
> people.
> 
> The problem with region modules..   and a scene interface..  is region
> modules use so many functions.   There is a LOT to try to encapsulate
> in an interface.   Here's the thing.   In the default implementation
> usage, most of them are important in really diverse region modules.
>  I can definitely think of a use for OtherRegionUp.
> 
> The other thing, is Scene-->SOG-->SOP is a bit too complicated for any
> single person to know everything about it.   This presents the
> question..  if the person doesn't know mostly everything about the
> system he's interfacing with, there's a very good chance it won't be
> as optimal as we'd like.   Certainly, at the planning stage, things
> will be missing..  and that will cause issues later to which we must
> implement nasty work arounds.
> 
> In Conclusion..   I'm mostly with Stefan here.   Though..    Given the
> complication, I don't really know where to start.      I think if we
> do go the Interface route, we must start respecting that people will
> be using it..  and therefore, if we make a change to it, we must
> notify people using the -dev list.   The notification doesn't have to
> be anything significant, just a note of what changed (including
> previous method signature, and new method signature).    If we do this
> at the time of the commit, then we, and the community can stay on top
> of what is changing in a way that is useful.
> 
> Best Regards
> 
> Teravus
> 
> 
> On 4/14/09, Justin Clark-Casey <jjustincc at googlemail.com> wrote:
>> 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?
>>
>> Yes.  Scene is too big (even forgetting about Scene.Inventory.cs for the moment).  There's still a lot of functionality
>> that can be broken into modules, I think, but it's getting quite difficult now (e.g. aspects of land which remain in
>> scene, and the whole of inventory management).
>>
>> >
>> > 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?
>>
>> Yeah, ISceneBase ain't a great name.  But I'm not too keen on ISceneForRegionModules either :).  ISceneAPI perhaps...
>>
>> Of course, this also doesn't take into account the big lump of stuff hanging around in SceneGraph either...
>>
>> >
>> > 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
>>
>>
>> --
>> 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
> 
> 