Usecase:
When using detectors, it is sometimes desirable to
force an execution order of detectors. Example:
- I am using the (more or less) standard updatenosy 
  auditor from nosyreaction.py
- Now I want to automagically fill in assigned_to on a 
  new issue for a certain class of new issues.
-> Not possible with the current implementation, at 
   least in my case the change of assigned_to will not 
   be propagated to the nosy list because the 
   updatenosy auditor gets executed *before* my custom 
   auditor setting assigned_to.

To remedy this I have implemented an optional parameter
"priority" to the audit and react registration methods.
It defaults to 100 and auditors/reactors are executed
in priority order.

The following changes were done to class Class in
hyperdb.py:
- factored two redundant copies of __init__ from
  back_anydbm and rdbms_common and a mostly redundant
  copy from back_metakit. The __init__ of back_metakit
  now calls the ancestor. Note that only back_metakit
  uses "self.db = db" -- while the other backends use
  weakref.proxy, I don't know if this should be changed
  in back_metakit, I've retained the original
  semantics.
- Moved three redundant copies of the detector
  interface methods audit, fireAuditors, react,
  fireReactors from rdbms_common, back_anydbm,
  back_metakit to hyperdb.
- Cosmetic change: Modified the detector interface to
  use consistent naming. The action triggering the
  detector was named "event" in audit and react, while
  it was named "action" in the fire methods. I'm now
  using "action" in all cases.

To implement the priorities the following changes were
made:
- Added class PrioList to support.py
- Made the lists of auditors instances of PrioList in
  hyperdb.py
- Added a parameter priority to audit and react
  methods, default is 100.
- Allow multiple registration of an auditor or reactor:
  Previously the registration method would check if the
  auditor/reactor was already in the list (by scanning
  the list). I have removed this feature: It might well
  be that in some situations multiple execution of a
  reactor or auditor was required.
- Insert the tuple (priority, detector) instead of
  detector only into the list of auditors/reactors
  respectively
- Use list-unpacking when fireing detectors

Patch is only tested with PostgreSQL backend. Note that
the code in support.PrioList probably needs at least
Python2.3, I'm making use of list comprehension and the
iterator interface. What is the version roundup is now
supporting?

Patch is against a modified version of 0.8.4. If this
won't apply for you, I'd be glad to supply a patch
against the current development branch from cvs.

I'm working on the necessary documentation changes and
will submit them as another patch when ready.

Ralf

Logged In: YES 
user_id=34818

Another patch: I consistently used "action" for the type of
the detector (e.g. retire, create, ...). Seems that the
design document consistently uses "event". The second patch
uses "event" consistently in the code. It is relative to the
first patch.

Logged In: YES 
user_id=34818

Documentation patch attached (relative to cvs from some
minutes ago). I've changed doc/design.txt to include the
priority parameter in the detector registration methods.
I've added a short sentence explaining the semantics. I've
also deleted the "New methods" part of the description of a
backend: I've moved the detector stuff to hyperdb because it
was redundant in all the backends.

Seems the customisation docs don't mention the detector
registration at all and refer to the design document, so I
didn't make any changes to the customisation docs.