[dev] IMP dynamic redirection

[Jan Schneider]

Zitat von Michael M Slusarz <slusarz at bigworm.colorado.edu>:

> Quoting Stuart Bingë <s.binge at codefusion.co.za>:
>
>> Hi Michael,
>>
>> On Tuesday 06 April 2004 00:56, Michael M Slusarz wrote:
>>> 1) _imp_hook_mbox_icon() was changed to return an array of mailbox/icon
>>> pairs instead of a single image URL to reduce to one function call (instead
>>> of potentially a function call each time a folder was displayed)
>>
>> Just got a chance to look at the change you made - I can see why you would
>> want to do this, from a performance perspective. Unfortunately this 
>> creates a
>> problem for the way we handle things:
>>
>> What we do with the Kolab server is store a hidden message of a specific
>> format in each IMAP folder, which tells us what type of folder it is
>> (Calendar, Task List, Notepad, etc). With the way I had implemented the icon
>> hook we were able to open the folder that was passed as the parameter, read
>> the hidden message from the folder (if one exists), and return the relevant
>> icon depending on the folder type. I thought this was the best way as it
>> simplifies the hook function immensely, as we could then rely on IMP 
>> handling
>> the mailbox tree however it saw fit.
>>
>> With the way you're doing it now, we're going to have to build the 
>> IMAP folder
>> listing ourselves within the hook function and go through each folder,
>> reading in our hidden messages and populating the icon array accordingly.
>> This is not necessarily a major problem for us to do - all it means is our
>> hook is now slightly more complex. The only problem I could forsee with this
>> is if our way of building the mailbox tree differs somehow from the way that
>> IMP does things, which could lead to us having two different mailbox trees.
>>
>> I haven't looked very closely at IMP's internals - are there perhaps 
>> a couple
>> of functions we could call to get the folder tree from IMP? If so then
>> there's no problem with the changes you've made.
>>
>> What do you think of this problem?
>
> How about a compromise.  The hook will continue to return the entire
> icon/folder
> mapping list if no arguments are passed in, and will pass back just the icon
> URL if a mailbox/folder name is passed in.
>
> How does that sound?

I don't think this would help because they would still have to implement the
"all folders" alternative. We should stick with one way to call the hook.

Jan.

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