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: jjusti...@googlemail.com >> To: opensim-dev@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@lists.berlios.de >> https://lists.berlios.de/mailman/listinfo/opensim-dev > > > > ------------------------------------------------------------------------ > > _______________________________________________ > Opensim-dev mailing list > Opensim-dev@lists.berlios.de > https://lists.berlios.de/mailman/listinfo/opensim-dev _______________________________________________ Opensim-dev mailing list Opensim-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/opensim-dev