dovecot - May 2004 - IMAP views - and things to make Outlook Express not suck so much

Some of the things that keep being brought up SEEM TO ME to be a form of
IMAP crack that can be accomplished in a much more generalized manner
with a little bit of thought.

An idea I had a while back was for IMAP views. It accomplishes the four
things I keep seeing on this list without being specific to any of them.

Consider new configuration variables:

rewrite Junk {
	folder = INBOX
	search = KEYWORD "Junk"	
	post = +FLAGS (Junk)
}
rewrite Trash {
	folder = *
	search = DELETED
	fetch = -FLAGS (\Deleted)
	post = +FLAGS (\Deleted)
}

Views would not be deletable (unless one wants to invent some
nonstandard IMAP extensions today), but they would otherwise look like
regular folders. One could post and search and fetch messages as normal
(with some alterations to various IMAP fields).

In the examples I gave:

A001 SELECT Junk
A002 SEARCH ALL
A003 SELECT Trash
A004 SEARCH ALL
A005 FETCH 1 FLAGS

would be translated into:

A001 SELECT INBOX
A002 SEARCH ALL KEYWORD Junk
A003 SELECT {for each SUBSCRIBED folder}
A004 SEARCH ALL DELETED
A005 FETCH 1 FLAGS

Except, A005 would actually yield:
* 1 FETCH (FLAGS ())

Instead of:
* 1 FETCH (FLAGS (\Deleted))

It would probably be ideal if these were configurable per-user, but I'd
be happy with system-wide rewriting.

Options for rewrite could include:
	folder 		folders that could be selected using LSUB OR a
		valid (existing) folder name. If this is system wide,
		pretty much only INBOX, INBOX.% and INBOX.* and * and %
		are valid :)
	search 		tags to append to SEARCH operations on the view
	fetch 		IMAP fields that are acceptable to STORE that we will
		pretend occurred when fetching.
	recent 		IMAP fields that should be STORE'd when the \Recent flag
		is still set.
	post 		IMAP fields that are acceptable to STORE that we will
		perform when APPENDing or STOREing.
	append 		argument to be passed to /bin/sh -c which will receive
		on standard input the APPENDed body, and produce on
		output a STOREed body.
	open 		argument for /bin/sh -c for when this view is
		SELECTed or EXAMINEd
	close 		argument to be passed to /bin/sh -c for when the
		view is closed.
	index 		argument to be passed to /bin/sh -c for when dovecot
		wants to index a portion of the message. standard
		input of the argument is the message, whereas
		standard output is the portion to actually index.
	path 		a regular dovecot mailbox path that would contain the
		real contents of this folder.

	ro path 		like path, but would be decidedly read-only (except for
		any side-effects generated by append =)

Subprocesses that exit 99 would handle the task internally- thus any
normal actions (such as for index = and append =) would not occur. Exit
code 0 is for normal completion, and all other exit codes should
generate an error.
	

If one allowed open = and close = to be used on REAL folders, this would
allow people to actually have the behavior UW-IMAP does by MOVING mail
from /v/s/m into ~/mbox...

One could use append = with a "Outbox" view that could write the queue
at the same time as storing a copy into Sent Items. One could also use
append for gpg-signing messages as they're being recorded. One could
also use append for publishing to a mailing list.

One could use index = to spell-check messages beforehand thus improving
my chances of actually finding messages from my PHB.

One could also use append =, recent = and ro path = to emulate shared
folders support in a manner that would be useful for using IMAP folders
as a kind of work-queue.

Thoughts?

On Wed, 2004-05-26 at 21:43, Geo Carncross wrote:
> An idea I had a while back was for IMAP views. It accomplishes the four
> things I keep seeing on this list without being specific to any of them.
I've thought about something similiar before, but I've mostly just
thought about performance and complexity issues with it. Creating a
single view from many mailboxes could be slow without some special
indexing.

Good ideas anyway, I'll think about them more once I get around to
implementing the thing (unless someone else wants to? :), sometimes
after v1.0.

Simple open/close/append triggers would be easier to implement, those
could be done with a plugin.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
URL:
<http://dovecot.org/pipermail/dovecot/attachments/20040526/e084be2f/attachment-0001.bin>

On Wed, May 26, 2004 at 10:34:36PM +0300, Timo Sirainen
wrote:
> On Wed, 2004-05-26 at 21:43, Geo Carncross wrote:
> > An idea I had a while back was for IMAP views. It accomplishes the
four
> > things I keep seeing on this list without being specific to any of
them.
> 
> I've thought about something similiar before, but I've mostly just
> thought about performance and complexity issues with it. Creating a
> single view from many mailboxes could be slow without some special
> indexing.
Just as an implementation point; it would be good if the specification
language was Sieve.

J

-- 
Joshua Goodall                           "as modern as tomorrow
afternoon"
joshua at roughtrade.net                                       - FW109

On Wed, 2004-05-26 at 15:34, Timo Sirainen wrote:
> On Wed, 2004-05-26 at 21:43, Geo Carncross wrote:
> > An idea I had a while back was for IMAP views. It accomplishes the
four
> > things I keep seeing on this list without being specific to any of
them.
> 
> I've thought about something similiar before, but I've mostly just
> thought about performance and complexity issues with it. Creating a
> single view from many mailboxes could be slow without some special
> indexing.
It shouldn't be slower than performing the actions manually. The only
"tricky" part would be the UIDL/ID matchups. If one is willing to
implement 64-bit integers, or accept a 2^32 maximal limit on the number
of messages accessible in a view, then the problem can be reduced to
m=n*nfol+folnum where nfol is the number of subscribed folders, folnum
is the relay counter, n is the original UIDL or ID number, and m is the
resulting UIDL/ID passed to the client.

Am I missing something about dovecot's implementation?