In Canada, we developed the necessary infrastructure to support frameworks and components, and added a first framework: OS_Detect. We wrote a component for this framework -- one that identifies OS X (because we were doing most of the testing/development on my powerbook).

The following sample code shows through example how it works:

-----
# Call the OS_Detect framework to find a suitable component.
# This only needs to happen *once*.
die "Cannot continue\n"
        if (! OSCAR::OCA::OS_Detect::open());

# Call the selected component to get this platform's info.
# This can be called many times throughout the OSCAR code (it's fast).
my $ident = $OS_Detect->{query}();
print Dumper($ident);
-----

The Dumper part is so that you can see that you get a hash back with info about this OS/platform.

The idea here is that you call the OS_Detect framework's "open" call which does all the work of finding suitable components, opening them, finding out if they want to run, etc. Once all this is done, it saves the function references into the global hash reference $OS_Detect. For the OS_Detect framework, there's only one method in its components -- a "query" function. So the funky syntax you see on the "my $ident..." line is invoking the query method on the selected component.

Keep in mind: this is the first framework, and it's darn simple. Each framework can be different, because they're going to be targeted at different tasks. So other frameworks may have lots of function references in its global variable, and there may even be some cached data (although one should be wary of doing that). Indeed, some frameworks may select multiple components, and a global variable (such as $OS_Detect) may not be suitable, or may contain a list.

Most specifically: the rules and policies for each framework are likely to be "similar" to each other, but definitely different in their details. Be sure to RTFM (or talk to the relevant developer) before trying to use a framework.

-----

Random notes:

- Frameworks are .pm files under lib/OSCAR/OCA (OCA = OSCAR Component Architecture). See lib/OSCAR/OCA/OS_Detect.pm for an example. Follow good perl module conventions for framework names.

- Components are .pm files in directories named by framework. For example: lib/OSCAR/OCA/OS_Detect/OSX.pm. If a component is suitably complicated and needs to be larger than a single .pm file, it can have a directory of its own name under the framework and do whatever it wants in there (e.g., lib/OSCAR/OCA/OS_Detect/OSX/...whatever...).

- The OS_Detect components are our gatekeepers for weeding out unsupported platforms/distributions. That is, we should only have components that identify supported platforms. For example: say that we have a Redhat.pm component that detects Redhat 9. If it detects Redhat 8.x, it should *not* return successfully. It should *only* return successfully when it can identify that platform successfully (i.e., "successfully" = "supported platform"). See lib/OSCAR/OCA/OS_Detect/OSX.pm for an example of this concept.

- During the opening / selection phase, components are "require"d by the OCA to load them into memory. Components should perform whatever logic is necessary to see if they can run. If they cannot run, they should fail -- and therefore disallow themselves from being required. Specifically, return false from the global scope in the file, so that the upper-level "require" will fail. In the case of OS_Detect, components should only allow themselves to be loaded if they can correctly identify the current OS/platform. As such, there should only be exactly *ONE* OS_Detect component that returns successfully on any given OS/platform. If !=1 OS_Detect components are returned, an error occurs and the OS_Detect framework will abort (because either you're on an unsupported platform, or there was some kind of error where multiple components allowed themselves to be loaded).

- Perhaps the next logical target for componentization is PackMan/DepMan (these should be 2 different frameworks, IMNSHO). This should greatly help the Debian guys, for example. Shouldn't be that hard to convert, IMHO.

--
{+} Jeff Squyres
{+} [EMAIL PROTECTED]
{+} http://www.lam-mpi.org/



-------------------------------------------------------
This SF.Net email is sponsored by Oracle Space Sweepstakes
Want to be the first software developer in space?
Enter now for the Oracle Space Sweepstakes!
http://ads.osdn.com/?ad_id=7412&alloc_id=16344&op=click
_______________________________________________
Oscar-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/oscar-devel

Reply via email to