[dev] Re: Adding contact to nag task [Patch]

[Chuck Hagenbuch]

Quoting Jeroen Huinink <j.huinink at wanadoo.nl>:

> Using the Turba registry I can express the fact that you can link into it
> with function like those I already mentioned. This is how we add "authors" 
> to Gollem documents. How can I express through the Gollem registry that it
> is usefull for Turba to have an "Authored documents" button somewhere?
> I can probably come up with something or look into the RDF, xlink or
> similar specs and see how they handle this, but it would be usefull if
> somebody with knowledge or ideas in this area would put in his
> suggestions.

This is exactly what the registry system is intended to provide. In this
case, it may be useful to have an overall method (implemented by Horde
itself), such as:

listRelationships($type)

... which lists all relationships of $type, where $type could be: contact,
project, task, etc. So Turba would call listRelationships('contact') and get
back that Gollem has a listFilesByContact() method (or some such). It might
also get back that Hermes has a listClients() method, also linked to Turba,
and so be able to display links for both of those.

That make sense?

> I was thinking about storing "contacts" in the application field instead
> of "turba". I haven't really thought about having two applications 
> providing "contacts" is that even possible in Horde. If you use a 
> "contacts" API, how do you determine which one to use in such a case? I 
> think my approach solves your problem. If it could even exist within the 
> Horde framework though.

Yup. (referring explicitly to how things work in HEAD here; it has been
different in the past). Applications claim an API - or a portion of it - by
setting a 'provides' attribute in their registry.php listing. So IMP has a:

    'provides' => 'mail',

entry, meaning that it claims the Mail API (Note: in the case of two
applications claiming the same API, I believe that the last one to be
defined wins, but this isn't really defined behavior). Also note that SAM (a
tool for configuring SpamAssassin) has this:

    // 'provides' => array('mail/blacklistFrom', 'mail/showBlacklist'),

This means that SAM claims *only* those two methods. If that line is left
commented out, IMP provides those methods as part of the overall mail/* api.
You can also do the same thing (claim those two methods) with Ingo, a
frontend for Sieve.

So the whole thing is pretty darn flexible, if I do say so myself.

-chuck

--
Charles Hagenbuch, <chuck at horde.org>
must ... find ... acorns ... *thud*