Quoting Marc Perkel <marc@perkel.com>:
Here's some thoughts I'd like to throw out there. I know it's not standard IMAP protocol but someone has to try new ideas first and I want to see what people (Timo) think of this.
I don't think you will find many supporters, other than the usual crowd who always wants SMTP over IMAP support.
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).
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.
parameters passed. For example, suppose there is a command to add a user to a server side blacklist.
100 execute blacklist add joe@smith.com 100 ok
You'd be better off with a generic "add" which took paramters like:
100 add blacklist joe@smith.com 101 add user joe@mydomain.com 102 add whitelist joe@jones.com
You'd then of course have a "remove" or similar named function to undo the add. You could also do a "set" or "modify" and so on.
The first argument to "add" (or whatever) would say what to execute (via a map file/table, for example). This makes the implementation a bit more generic and independent of any executable.
Dovecot would open a two way connection to the server application allowing the client to talk to any application that is configured and can send and receive text. The connection persists until the server end terminates or the client closes the connection.
I'd rather see these as "plugin" type applications, but that certainly limits their adoption...
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...
Not only can setting be changes but you could interact with server side calendars, pick up voice messages from phone systems, run any sort of groupware, all over a generic IMAP connection with this simple extension.
This is more like the "mode" idea I mention above, IMHO.
Example:
100 EXECUTE calendar 100 ok 100 list schedule today 8:00 10:00 100 8:00 make coffee 100 9:00 meeting with boss 100 9:30 Call Joe Blow at 415-555-1212 100 ok 100 quit 100 ok
And when "quit" happens, what mode are you in? What if the task executed changed the IMAP state, how would IMAP know that? Seems like keeping track of state would be next to impossible, and would require the IMAP session to reinitialize after the execute command, which would be about the same overhead as just using another connection in the first place (a bit less, but...).
In other words, unless the task executed was specified as to never change the IMAP universe (couldn't deal with SPAM filtering, password changing, sorting/deleting/adding mail/folders, etc) then when it was done executing the IMAP server would have to re-initialize to catch any changes, and this kind of defeats the purpose of the proposal IMHO.
One thing I'd like to use it for is an outgoing SMTP connection to send outgoing email over IMAP. A session might look like this:
Yeah, I knew that was coming. :) And of course, this very well could change the IMAP environment, and hence would require an IMAP session reset, which means why do it?
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.
-- Eric Rostetter The Department of Physics The University of Texas at Austin
Go Longhorns!