[dev] Exciting find

[Chuck Hagenbuch]

Quoting Jan Schneider <jan at horde.org>:

> Zitat von Michael M Slusarz <slusarz at horde.org>:
>
>> Once this is done and I have tested for a bit, I'm going to slowly  
>> replace (function by function) the current imap_* calls in IMP.   
>> One note: this is going to break POP3 in HEAD since there will be  
>> no corresponding driver once in Horde_Imap_Client that supports  
>> POP3 (do we want to continue supporting POP 3 in IMP 5?  Or else  
>> someone will have to write a POP3 driver for Horde_Imap_Client  
>> although this really isn't high on my priority list).
>
> Yes, I think we should keep supporting POP3. Even though POP3 sucks,  
> it one of the nice features that IMP is working with any mail server.
> But if I understand the library correctly, POP3 support should still  
> work with the c-client driver, just not with the socket driver,  
> correct?

I think it would be great to structure our code such that someone who  
wanted to add POP3 support could, and someone who wanted to have IMP  
talk directly to a SQL database could as well. I don't think that both  
of those need to be encapsulated in Horde_Imap_Client, though; I think  
if we do this, it should be done at the IMP level, with a library that  
encapsulates all access to the underlying message store. Kind of an  
Imp_Mapper object, in the Rdo sense, with different mappers for IMAP,  
POP, SQL, etc.

I'm not going to insist we do this from day one, though if others  
agree it's worth doing, then it might be easiest to do it while  
replacing imap_* calls. If no one think this is useful, then let's  
adjust the name of Horde_Imap_Client to allow for variant  
implementations that aren't IMAP (Horde_Mail_Store? eh...), and let  
POP3 lag while all of this is under development.

-chuck