Rejecting this particular implementation. Several Horde 4 features 
will address something like this.

Stalling this for now.

For the archives I attach here the discussion we just had on IRC.

Carlos: I still think that Notification is a better place to put the 
_messaging_ part of this. You'd still need some place to manage 
observers, but because Notification is already built in to Horde, 
having a Notification_Listener_observer class could make this 
relatively transparent.



Jason: Memento is a good idea. Why Site? Doesn't mean anything to me. 
I'd prefer ObserverManager (just kill the _, it's not a subclass).

Here's an update to my tastes, see what you think:



1) Remove integer contstants, use strings like 'delete' instead.

2) Allow an observer to return false to abort.

3) Remove validateDeletion(), instead app would use notifyObservers() 
with a different "message".

4) $manager set by reference in ::singleton().



A couple of thoughts I wonder about:



* I'd prefer ObserverSite:: to Observer_Manager:: as the class name.

* What about using the Memento pattern in the ObserverSite:: and 
attached Observer:: instances and not directly talk to DataTree?  That 
way, whups can store the memento in the tickets table, for example.

I did think about using 'Notification_Listener' or 'Relationship'.

I can't remember the details but I decided not to use any of them.

In fact, I'd rather use the Observer mechanism as the way to 
(re)implement the Notification_Listener (in a second step indeed) and 
not the other way round.

Basically the Observer Mechanism is more generic than the 
Notification_Listener stuff and could easily be applied for several 
things (Notification_Listener included).

Has anyone considered doing this with Notification_Listener objects? 
Or Log_Observer? I think those two existing mechanisms might provide 
almost everything that we want for this, except the storage specifics 
- and that might not even be the same in all cases anyway.

Bug #916 (just solved) is another example where this mechanism could 
have been applied, centralizing the mailing mechanism for all the 
different applications in just one place, thus reducing potential bugs.

It's certainly not ruled out yet.

Just wondering if this idea is still under consideration.  We had a 
user submit a feature request that if someone added a task to your 
tasklist, an email notification would be generated.  It would seem 
that the Observer Mechanism would be a good, generic way to implement 
this type of functionality, for not only a task addition notification, 
but the other items that Carlos lists.

IMO, the class should wrap the DataTree usage. I don't think it's 
necessary for the class user to deal with DataTreeObject_Observers 
objects.

The Observer Design Pattern is a widely used technique for achieving 
flexible yet efficient run time notifications of some changes/events 
happened over some particular data/objects. An "observable" object has 
a list of "observers" and, whenever the "observable" object is 
modified it notifies each observer about the change so that they can 
act accordingly.



In pseudo-code .. this is the basic idea:



1.- Some modification over an object observed happens

2.- Look for this objects' observers

3.- For each of them: Notify Change



This is usually applied directly to the objects we wish to "observe" 
but in the case of Horde that would be a real mess as it would involve 
modifying an important number of objects. In order to adapt this 
pattern to Horde, I have created the skeleton of a new framework 
package (see attachment) that supports the storage of observers lists 
for each horde object based on the datatree backend (this could of 
course be ported to others). That way, in run time, when an object has 
been modified (e.g. an event has been added to a calendar, a new 
message has been posted in an Agora thread, a Whups ticket has been 
closed etc..) we can go and check in the Observers package whether we 
have any observer whishing to be informed about such a change. Each 
and every observer would then be notified thus triggering some 
updating mechanism, like sending an e-mail to a user etc...



Because communication between the different modules in Horde happens 
through the different API's, it would make sense to add there a method 
for performing the updates a la:



updateObjects(objectsIDs) {

  1.- Get the objects

  2.- Do some changes

  3.- Store the changes

}



Potential Uses:



1.- Support setting up watches over Agora threads

2.- Support this notifying users when an event has been added to their 
calendar.

3.- Support the Thor project planning mechanism allowing the 
activation of new tasks when their pre-conditions are fulfilled (i.e. 
previous needed task is finished).



Note: This would certainly solve your Planning vs. Workflow "problem" Jason.



There are many other possible uses of such a functionality which I 
believe would be really nice having.