Comment 4 for bug 100338

1.5 month ago I promised to send more ideas how to fix the current
problem. Well, here it is:

 The current flow of the messages on approvbla looks like:

   --------------------
   | |
   | tab_status |
   | |
   --------------------
         (1)|
            |
            | request status change
            |
         (n)|
   --------------------
   | |
   | Versioning.py |
   | |
   --------------------
         (n)|
            |
            | create messages
            |
         (1)|
   --------------------
   | |
   | service_messages |
   | |
   --------------------
            |
            V
    SMTPlib sends messages

To make this work, one needs an additional "send_pendig_messages"
call from the tab_status_ to the service_messages

Instead of creating the messages in the separate Versioning objects,
something else may perform the actual action, including assembling the
messages to be mailed. I think this "something else" should not be the
tab_status (would store application logic in the ui) and not the
service_messages (which should only send messages, nothing else).

 Thus I propose to define a new service, say "service_approval".
("service_workflow" seems to be a little too sophisticated, actually the
service does not allo to define new workflows.)

This would look like:

   --------------------
   | |
   | tab_status |
   | |
   --------------------
            |
            |
            | request status change
            |
            |
   -------------------- --------------------
   | | (1) (n)| |
   | service_approval |--------------------| Versioning.py |
   | | changes status | |
   -------------------- --------------------
         (1)|
            |
            | create message
            |
         (1)|
   --------------------
   | |
   | service_messages |
   | |
   --------------------
            |
            V
    SMTPlib sends message

 Now to implement a different notification mechanism than sending
emails around, one could:

  - implement a different approval service
    which treats the approval notification completely different

  - extend the member object to store information
    what kind of notification this person wants
    and change the approval service to either store
    the notifications in the member object or mail it
    (or both, maybe)

some more random remarks:

 Storing the pending requests in the Member object would have the
drawback that all pending requests have to be assigned to some single
Member, which is currently the nearest ChiefEditor. This may create a
bottleneck.

 Maybe cataloging and querying this information from somewhere may be a
better idea, as this preserves the information even if the object moves.
However I have little to no experience with catalogs yet and do not feel
very sure about howe to handle this.
 This may add some more burden to the versioned content stuff. Maybe it
is better to review this when the versioned meta data issue is done
(I guess this is http://issues.infrae.com/silva/issue196 ?)

Any comments on this? Maybe someone has suggestions on improving this,
or seeing something that still cannot be done or has a completely
different suggestion?

Otherwise I will go on with this issue after fixing issue189.