[dev] IMP dynamic redirection

[Michael M Slusarz]

Quoting Jan Schneider <jan at horde.org>:

> 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.

This has been sitting (festering) in my mailbox for weeks now.  What 
needs to be
done to resolve this?

michael

______________________________________________
Michael Slusarz [slusarz at bigworm.colorado.edu]
The University of Colorado at Boulder