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

Melanie melanie at t-data.com
Tue Apr 14 18:42:06 UTC 2009


A few points to consider:

- Should core really limit what _can_ be done by non-core module coders?
- Is it very likely that anyone would make a new Scene-type object 
without inheriting from Scene?

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. Any interface would just have to carry 
almost all methods of Scene anyway, and add yet another file to edit 
when adding fundamental functionality.

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.

Finally, I believe the requirement to submit a patch to expose 
methods needed for new functionality, and the possibility of 
rejection, would stifle innovation and make forge a joke.

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 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 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".

Melanie


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



More information about the Opensim-dev mailing list