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
[EMAIL PROTECTED]
