Melanie wrote: > 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.
Wrong. Scene contains many methods that are of no interest to modules or would actively be harmful if used (OtherRegionUp, StartTimer(), SetModuleInterfaces(), loadAllLandObjectsFromStorage(), etc., etc.). > > 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. It might be hard for you to believe, but I can very easily believe it. > > 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. Really, "stifle innovation", "make forge a joke" just by putting an interface on Scene? Taking such an extreme position does not do your argument any good - it makes you look shrill. > > 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. This is partly why it would only be put on the new region module mechanism, since that mechanism is going to break existing modules anyway. > > 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. Not having an interface a) Makes abstraction impossible - one always has to superclass scene b) Make it much more difficult for 3rd party modules to work out how to invoke the functionality that they need. Not everyone should have to read every inch of the code to understand what is going on. They should not have to rely on those who already have the knowledge (the core developers). If someone really wants to get at the guts then they can always cast to Scene. This is the price one pays for accessing internals, and people can't then complain about the lack of documentation or unexpected results of functions that they should not be accessing unless they really know what they are doing. In addition, anyone with purely private functionality who isn't going to share even the hooks necessary has to pay the cost of maintaining private patches. > > 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". What tosh. It would not be in the spirit of open source (BSD, GPL or otherwise) to make it as hard as possible for people to work out how to write modules by exposing lots of extraneous methods, some of which are dangerous and actively misleading in a project as complex as OpenSim. Like it or not, the migration of functionality to modules is putting things behind interfaces anyway. IScene will just be another step in this. > > 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 > -- 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
