Eric Rostetter wrote:
Here's my initial thoughts on this. Suppose we extended IMAP to include an EXECUTE command as follows:
You'd be better off either making these "generic action verbs" like "add" and "remove" (if each is meant to be self-sufficient, one-line actions), or calling them "modes" (if the idea is to switch contexts to some other protocol such as smtp, calendars, etc).
Generic action verbs are handy, but a LOT less flexible. They limit me to that set of actions for _all_ possible extensions... and whilst a good set can be found for many cases, the contortions it will force people into for cases that don't fit... well...
On the server side is a config file
Yes, that would be critical IMHO, or at least that there was some centralized way to control it, and not Dovecot-specific if you wanted the idea to spread past dovecot.
A general config form I like. My biggest concern on reading this was it opens one enormous can of security worms - albeit it self-inflicted by admins, essentially, Dovecot will still get blamed for making it easy.
With a tool like this one can write generic applications easily that would greatly expand what email clients can do interacting with the server.
Sure, but why not just use a protocol for each, rather than layering them on top of IMAP? Do you really think the overhead of opening a new connection is so great? Debugging sure would be easier if they are separate...
Whilst it does sort of make a step towards "IMAP as RPC", I think the nice thing about IMAP is the basic protocol level is quite solid - how to send/parse various data types, etc, is clear and clean, and is independent, pretty much, of the command set you implement. Take ACAP as an example - same low-level protocol, whole different command set.
Add to that the IMAP connection has already dealt with handshaking, authentication, and encryption...
Now, from what I've seen of Dovecot's innards, it probably wouldn't be too difficult to write your own protocol using the imap base, and build your own daemon...
Who likes this idea?
Not me. I think using different protocols for things...
Now, that doesn't mean dovecot couldn't support more protocols. Just as it already supports multiple protocols (pop3 and imap) it could add others... No reason not to, and not reason to piggy back them through the IMAP session, IMHO.
As you've probably guessed, I'm somewhat in favour of this approach. Dovecot as a base for more protocols. I like the IMAP base protocols, and Dovecot already provides the parsing and command dispatch for such.
One day... One day I'll have time... and in that time I'll try to implement a Calendar protocol, because I'm sick of all these polling-based implementations. But that will have to be after I hook LigHTTPd and Apache into Dovecot Auth, and .... all the billion other things I want to do :(
-- Curtis Maloney cmaloney@cardgate.net