Re: Infos about ActivityManager ... ??? (was: Issue EventHandlers Implementation ...)

Jorge Uriarte wrote:
> 
> sorry Hussayn; I think it's not activitymanager but the
> notificationmanager which can be easily extended (and it's indeed a
> hook in the middle of system activity).
> 

aahhhh...!!!! That makes sense for all notification related tasks, where
"notification"
means EMail, SMS, instant message, automatic phone call (using text to
speach)...
It would be the natural place to implement that as a NotificationManager.
Yes!!!
Indeed i can solve most of my current todos by creating a specialised
NotificationManager.

ok... but what is if the Notification is not an information transfer between
Scarab and users ?
What if the "notification" would be to change something inside an issue
(like calculating sums
of working hours and place the result into an attribute, sending an
automatic commit event to svn,
sending a Blog-entry to my marketing blog (well.. no, not that one ;-) ...
Such "things" can hardly 
be seen as "notification" in the sense, we do use it currently (as emails to
users).

MAYbe it is only a different name for the same thing, but i think it
clearifies the processes to
some extent:

In terms of "event" i think that the NotificationManager is a very special
Processor for 
"NotificationEvents", which are generated from an NotificationEventHandler
whenever an issue 
is saved.

So the Event system as i think of it is something much more basic. I even
see the Event system
running below the Notification system (the notification manager using the
eventsystem for its operation). 
If we had it already implemented, probably the Notification system would
have been implemented based 
on the Event-System:

- Each time an issue is saved, a NotificationEventHandler() is triggered.
  The Job of the NotificationEventHandler() is to create an entry in the
NotificationTable
  for each associated user and then self destroy.

- The NotificationManager is triggered periodically in the background to
process all Notification entries
   it finds in the NotificationTable


But besides the NotificationEventHandler, there can be many more and
different EventHandlers around
associated to an issueType, or module, or even to the whole Scarab-instance.

As an example a OnIssueSolvedEventHandler could be triggered, whenever the
attribute "solved-at date" is set (or changed). It simply calculates the
total amount of time between "solved at date" and "creation date", and fill
the result into the attribute "total time to solve".

Another EventHandler could maintain a watchdoglist which takes care about
issues in the state "forwarded to". A WatchdogProcessor can take care of
adding appropriate NotificationEntries into the NotificationSystem, whenever
an issue keeps too long within the state "forwarded to".

All we need to do is to define 2 API's:

- the api to the data which shall be available from within an EventHandler
(probably the Issue-data...)
- the api to the GUI, where EventHandlers shall be made configurable

All the rest, the purpose of an EventHandler can be completely left out of
the system, it is sort
of an "event based integration layer" ...

If we can manage this, we can keep Scarab fully independent from
specialities. Special cases
can then be implemented in MySpecialCaseEventHandler classes, added to the
configuration  
system, configured to run "under my special circumstances" for each
issueType individually...
IMHO that would make Scarab much more flexible regarding integration with
3rd parties products.

Please pull me back please, if i amn thinking too complex here ;-) ...

regards, 
Hussayn
-- 
View this message in context: http://www.nabble.com/Issue-EventHandlers-Implementation-...-tp21489747p21509780.html
Sent from the Scarab - Dev mailing list archive at Nabble.com.

------------------------------------------------------
http://scarab.tigris.org/ds/viewMessage.do?dsForumId=455&dsMessageId=1029575

To unsubscribe from this discussion, e-mail: [[email protected]].