[ingo] Selecting backends based on current Imp mail server

Jan Schneider jan at horde.org
Tue Mar 30 00:40:29 PST 2004


Zitat von Chris Hastie <lists at oak-wood.co.uk>:

> On Mon, 29 Mar 2004, Jan Schneider <jan at horde.org> wrote
>> Zitat von Chris Hastie <lists at oak-wood.co.uk>:
>>
>>> On Mon, 29 Mar 2004, Jan Schneider <jan at horde.org> wrote:
>>>
>>>> Zitat von Chris Hastie <lists at oak-wood.co.uk>:
>>>> >
>>>> > Is it possible to select backend based on the current mailserver that
>>>> > Imp is connected to?
>>>>
>>>> Not currently. But a patch would be great.
>>>>
>>>
>>> I may have a go if I get time. Can you suggest what is the best way 
>>> to access
>>> the current Imp server setting? Also, does Ingo need to be able to function
>>> independantly of Imp? I'm guessing it does.
>>
>> Yes, it does. The interaction should probably be done best with an api call.
>> "mail/getPreferredServer" or something similar.
>
> I had a think about this and a bit of a play yesterday evening. I could
> do with some feedback before I do anything finally. I could also do with
> doing a cvs update before I go any further, so if this is all completely
> irrelevant to the current code, sorry :(
>
> There are probably dozens of ways of arranging the interaction. I could
> think of three main ones:
>
> 1)  An additional parameter in ingo/config/backends.php, similar to
>     'preferred', where the mail server could be specified. If this
>     matches Imp's current mail server that backend is used. Possibly
>     even add it within the existing 'preferred' hierarchy, but this
>     makes backwards compatibility a bit more complicated. Possible
>     drawback is that mail server is not necessarily unique to an Imp
>     config - you may have two running on different ports on the same
>     host for example.
>
> 2)  Similar to one, but match on something more unique in the Imp
>     config, possibly 'name' or the key to $servers. Only the key can
>     really be guaranteed to be both present and unique, and I'm not sure
>     it's currently used much so it may be trickier to access.
>
> 3)  Come at it the other way around. Add an additional parameter to
>     imp/config/servers.php, say 'ingokey', specifying the key from the
>     $backends array to use with this particular Imp configuration.
>
> Whilst 3) does add an additional config parameter to the already
> considerable list for imp/config/servers.php, it looks to me to be much
> easier to code and arguably more intuitive to admins. So this is what I
> played with.
>
> Something like this should accomplish the task relatively easily:
>
> include INGO_BASE . '/config/backends.php';
> if (!isset($backends) || !is_array($backends)) {
>     Horde::fatal(PEAR::raiseError(_("No backends configured in 
> backends.php")), __FILE__, __LINE__);
> }
>
> if ($registry->hasMethod('mail/whichSieve')) {
>     $confkey = $registry->call('mail/whichSieve');
> }
>
> if (!empty($confkey) && isset($backends[$confkey])) {
>     $backend = $backends[$confkey];
> } else {
>     foreach ($backends as $temp) {
>         if (!isset($backend)) {
>            [... existing code]
>     }
> }
>
> Does it make sense to go down this route?
>
> The other question I have is do I need to add an Imp api function,
> mail/whichSieve in the above, to return the value of the 'ingokey'
> parameter, or can I just access $_SESSION['imp']['ingokey'] directly?
> Both work, but I've never quite grasped if one is better than the other,
> and why.

Try to KISS.

Add a mail/getPreferredServer or mail/getCurrentServer method to IMP's api
and you're done.
All that's left is to add an example how to use that method to the comments
of Ingo's backends.php, because you can now do something like:

[...]
'preferred' => $GLOBALS['registry']->call('mail/getCurrentServer'),
[...]

Jan.

--
http://www.horde.org - The Horde Project
http://www.ammma.de - Neue Wege des Lernens
http://www.tip4all.de - Deine private Tippgemeinschaft


More information about the ingo mailing list