IIRC, we have some central detection engine and then lots of different places base "if" logic off the results from the detection engine.
I'd like to propose to change this -- to make OSCAR more framework-ish. The goal here is to make OSCAR be easier to extend by third parties (and our sister projects -- HA-OSCAR, SSS-OSCAR, Thin-OSCAR, Debian OSCAR, etc.), yet still easily be able to stay in sync with the main OSCAR code base.
1. Keep the central detection engine, but make it plug-in capable. That is, don't make adding a new distro a matter of *editing* a file, but rather *adding* a file. This is trivially easy to do (e.g., run through all the scripts in a given directory that match a given pattern [e.g., "os_detect_*.pm"] -- the plugins for OS detection -- and see which, if any, return a valid "yes, I recognize this OS -- here's the name and version").
--> This allows others to extend OSCAR without modification of our code base -- an important feature. They can just *add* a file and OSCAR automatically picks it up and uses it. Specifically, if a 3rd party *modifies* our code base, that 3rd party has to keep their patch up-to-date with every version of our code base (which may or may not be easy). *Adding* a file, as long as we keep the directory and regexp name the same, is trivial to do.
2. Remove all of the "if"-based logic throughout OSCAR that is dependent upon the OS name/version and instead, use directory-based approaches. For example, the vast majority of OSCAR package "setup" scripts simply copy RPMs from an OS/distro-specific directory to the top-level package RPM's script. This should be trivial to parameterize and add to the common OSCAR code core. Perhaps all these setup scripts become one-line scripts:
OSCAR::copy_binary_packages($my_package_name);
This can find the appropriate subdir under $packageroot/distro and copy all the files to $packageroot/RPMS (we're going to need to rename the "RPMS" and "SRPMS" directories soon! :-) ).
Elsewhere in OSCAR logic where "if" results are used based on the OS/distro/version, I'll bet that those can be intelligently parameterized to use some kind of generic top-level function, perhaps with a user callback, to do whatever is necessary, but have the list of input a) dynamically determined at run-time by examining the contents of a OS/distro/version-specific subdirectory b) that was identified by the detection engine. Perhaps something like:
OSCAR::do_os_distro_action($top_subdir, \&callback_action);
where $top_subdir is the root of the tree to examine for the OS/distro/version subdirectories, and &callback_action will be invoked with a list of all the files from the subdirectory that the detection engine identified (or an empty list if no matching subdirectory exists).
This is off the top of my head -- I'm sure that more refinement will be necessary.
--> This makes it even easier to add support for a new OS/distro/version -- no logic needs to be changed. All you have to do is add new directories with new RPMs (or whatever binary package is used on that platform) and a plugin for the detection engine. The OSCAR logic will then pick up your new plugin and (for example) the OSCAR setup scripts will automatically choose the right subdir to copy the right binary packages... etc. You get the idea.
--> This also opens the door -- in a much more realistic way -- for OS/distro/version-specific OSCAR distribution tarballs.
Comments?
I think this fits in with the long-term framework plans that Thomas presented at the Jan meeting (I'm obviously not talking about 4.1 here). I just wanted to put a concrete proposal out there since it occurred to me this morning. :-)
--
{+} Jeff Squyres
{+} [EMAIL PROTECTED]
{+} http://www.lam-mpi.org/------------------------------------------------------- SF email is sponsored by - The IT Product Guide Read honest & candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click _______________________________________________ Oscar-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/oscar-devel
