[dev] [commits] Horde branch master updated. 71c1d5b996bac5e3df65edb1aad2b11ca573a0cb

[Michael M Slusarz]

Quoting Jan Schneider <jan at horde.org>:

>>    Add listAlarms() to methods provided by Horde_Core_Registry_Application
>>
>>    This is not an API method - which are unique to each application - but
>>    instead an Application method since it requires the same function
>>    signature across all applications.
>
> I was never sure where exactly we do the cut between Application and  
> API methods. This distinction makes sense too, but for me it was  
> always a more important criterion whether the method makes sense as  
> an external API method, i.e. whether it's a method that could  
> potentially be used from an external consumer, and has a signature  
> that can be easily be used even from a non-Horde context.

I think in this case, if it makes sense to provide a list of alarms to  
an external consumer, then you should add a separate alarms method to  
that application's API.  For something like IMP, this is not going to  
make much sense since alarm notifications are nothing more than  
parsing the contents of IMAP output, which can be obtained via other  
API methods.  For kronolith, an alarms method is probably needed since  
the data analyzed to create the alarms is internal to kronolith so  
this is the only way to determine this .

The distinction here seemed fairly easy since there was code in  
horde/Alarm that did nothing more than loop through all applications  
and look for a listAlarms() method.  So this method has to be  
standardized across all applications, or else things wouldn't work  
properly or as expected.

Final note: A gigantic chunk of horde/Alarm relies on horde/Core.  We  
should probably deal with that before the stable releases are  
finalized (?)

michael

___________________________________
Michael Slusarz [slusarz at horde.org]