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...

CommentFileSizeAuthor
#2 metrics_times.api_.php_.txt2.85 KBhunmonk

Comments

hunmonk’s picture

function signature makes sense for the info hook.

definitely in favor of the array of nids option for the compute functions.

hunmonk’s picture

StatusFileSize
new2.85 KB

attached 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.

hunmonk’s picture

this 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).

hunmonk’s picture

ok, 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:

  1. test the design of the API -- i've already made several API adjustments just by trying to actually use it :P
  2. we can use it for the sprint demo

couple of things i learned writing the example module:

  1. being able to specify custom callback for fetching the object ids and calculating the metrics values is a good thing. for fetching the objects, it's entirely possible that an existing function will be able to provide that data (for example, project module can provide the function to return the list of projects to track, and other project-related modules can simply use that function to return their list). for the calculations, having a default function invocation will work for simple cases, but with a lot of metrics, we don't want to end up with one monster function with a giant switch.
  2. i originally thought there was a need to provide attributes to pass arguments to the custom callbacks, but after trying to find an actual use case for that in the example module and failing, they now seem unnecessary. all callbacks already get the name of the metric, and i couldn't think of a case where the callback would really need much more than that.

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).

hunmonk’s picture

Status: Active » Fixed

the example module is finished, and i believe that addressed all of the relevant tasks in this issue.

hunmonk’s picture

Project: Project » Drupal.org Redesign
Version: 6.x-1.x-dev »
Component: Metrics » Everything Else
Assigned: Unassigned » hunmonk
Issue tags: -project metrics +metrics

no official project exists for this module yet. moving to redesign queue for now, and retagging

hunmonk’s picture

Project: Drupal.org Redesign » Sampler API
Version: » 6.x-1.x-dev
Component: Everything Else » Code

moving this issue to the new module's home...

hunmonk’s picture

just 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().

Status: Fixed » Closed (fixed)
Issue tags: -drupal.org redesign, -drupal.org redesign project, -drupal.org redesign sprint 3, -metrics

Automatically closed -- issue fixed for 2 weeks with no activity.