Subtask of #79550: Automate gathering of quality metrics and Project metrics for drupal.org redesign:
We're going to want something like hook_project_metrics_info() that returns a nested array of information about specific metrics. The keys in the array are the metric deltas (sort of like hook_block_info() in D7), and the values are structured arrays to define stuff like the human-readable title of the metric, perhaps a description of the metric, an optional key to define the data type of the metric (defaults to int), a function callback to invoke when the metric should be computed, etc.
This issue is for nailing down the details, documenting them in project_metrics.api.php, and adding a project_metrics_info_load() function that invokes the hook (probably with its own static cache).
One interesting question to resolve is what kind of function signature the "compute me" callbacks should have. Do they take a $nid argument and just give you the value for that project, do they expect an array of nids to compute metrics for, or do they return an array of metrics (keyed by project nid) for all projects they know about? I'm wary of premature optimization and making this more complicated than it needs to be. OTOH, we're talking about ~7000 modules on d.o, so some of this stuff is going to be expensive to do for all modules in a single function. Flip side is that's a *lot* of function invocations and separate queries if we always do everything 1 project at a time. So, probably an array of nids to compute for is best, since it will allow any possible approach once we get some experience with the RAM vs. DB pounding tradeoffs...
| Comment | File | Size | Author |
|---|---|---|---|
| #2 | metrics_times.api_.php_.txt | 2.85 KB | hunmonk |
Comments
Comment #1
hunmonk commentedfunction signature makes sense for the info hook.
definitely in favor of the array of nids option for the compute functions.
Comment #2
hunmonk commentedattached is my first crack at the API documentation. over at #889886: Create a metrics backend framework module it's looking like we might try for a more generally useful module, so i've just called it 'metrics_times' for now.
Comment #3
hunmonk commentedthis is coming along nicely. i pretty much have the .install file and .api.php files done, and i've written the loader for the metrics_info hook. i'll post progress tomorrow.
the only sticky thing i've run into: i'm not finding an easy way to act when a module is installed or uninstalled. hook_install(), hook_enable(), and hook_uninstall() are all only called for the module being installed, enabled, or uninstalled. outside of doing hackish detection at admin/build/modules, does anybody know of a way that i can detect this in drupal 6?
i think having this ability would smooth out the table management for the modules that advertise metrics (eg., when a new one is installed or an old one is uninstalled).
Comment #4
hunmonk commentedok, instead of posting patches here, mikey_p suggested that we go the sandbox route:
http://drupalcode.org/viewvc/drupal/contributions/sandbox/thehunmonkgrou...
i've decided against an api.php file in favor of just writing a small example module. this working example approach has a couple of benefits:
couple of things i learned writing the example module:
so, i believe the following attributes will be all we need to make things work: title, description (required), data_type, object_ids_callback, calculation_callback (optional w/ default values).
Comment #5
hunmonk commentedthe example module is finished, and i believe that addressed all of the relevant tasks in this issue.
Comment #6
hunmonk commentedno official project exists for this module yet. moving to redesign queue for now, and retagging
Comment #7
hunmonk commentedmoving this issue to the new module's home...
Comment #8
hunmonk commentedjust a note that because of the rewrite mentioned at #889886-13: Create a metrics backend framework module, and moving the module namespace, the hook for advertising metrics is now hook_sampler_metircs().