[dev] Exciting find

Jan Schneider jan at horde.org
Thu Sep 18 07:48:23 UTC 2008


Zitat von Michael M Slusarz <slusarz at horde.org>:

> Quoting Chuck Hagenbuch <chuck at horde.org>:
>
>>> 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?
>
> Thinking about this, this is probably half doable.  Yes we can still  
> use the imap_* commands, but the way I am writing the driver it is  
> pretty IMAP specific in the Cclient driver.  Writing a  
> 'Cclient-pop3' driver to extend the Cclient driver is probably the  
> way to go for this (at least a the beginning).
>
>> 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.
>
> I don't object to this goal but I'm wondering if this is a goal more  
> worthy for the IMAP backend rather than an IMAP client.  We need to  
> have some kind of workable mail access API, and it seems as  
> reasonable as any to use the IMAP API to access a mailstore.  So if  
> other drivers/backends are to implement a pseudo-IMAP API, it is  
> probably best to let the IMAP server handle that rather than  
> Horde/IMP (e.g. http://www.dbmail.org/).  Starting to do more than  
> this at the IMP level would quickly get us away from our core goal:  
> providing a MUA.

I agree, and this saves us another level of abstraction. We should  
also add a mock driver, similar to the one in Ingo, so that we can  
create imap/mailstore based unit tests more easily.

Jan.

-- 
Do you need professional PHP or Horde consulting?
http://horde.org/consulting/



More information about the dev mailing list