nmh-workers
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Nmh-workers] exciting new stuff for 2.0 (IMAP proposal)


From: Mike O'Dell
Subject: Re: [Nmh-workers] exciting new stuff for 2.0 (IMAP proposal)
Date: Sun, 08 Jan 2006 10:51:56 -0500
User-agent: Thunderbird 1.4 (Macintosh/20050908)

the GUI is not for "IMAP" - it's a interface for a email UA.
IMAP is but one *implementation* of a folder mechanism,
not something that should be revealed any more than
is strictly necessary.  the fact that IMAP might need
collateral metadata to implement the desired abstraction
is a damn  nuisance, if not outright bug, and certainly not a feature.

MH already has a rich model for "folders", and that
should be respected deeply - it is the principal attraction of MH!

it is instructive to consider the rich semantics already
provided by the underlying filesystems and how they might be used
as a model.

there are several alternatives one can imagine, but i'll
give an example that appeals to my sense of "minimal extension"
while avoiding "semantic sugar" as wallpaper paste.

one might be to extend the
notion of "mountpoints" already present in the environment:
a folder directory exists to anchor an IMAP folder tree
and the directory is indicated by a distinguished file
in the directory, possibly containing required metadata.
this would allow arbitrarily many IMAP accounts to be
mounted within a folder structure without changing the
structure or syntax of "foldernames". if symlinks are
used which resolve into the IMAP tree (the symlink evaluation
will have to be done in the folder access routines, but
that's a small job), then one can provide aliases at the
top level as desired.

if we couple this with the notion of "union mounts" by
allowing the "Path:" component in .mh_profile to specify
a list of directories, then IMAP hierarchies can be
laminated onto local directories, providing complete
transparency for users.

the value of such transparency should not be overlooked.
email users having to understand a great deal about where
their mail is stored is a serious problem - that's one of
the great virtues of MS Outlook.  (It has many other things
to disrecommend it, but the operational model and its ease
of use for many purposes is instructive to consider.)

we don't need a lot of new "goop" to deal with IMAP.
the Unix filesystem model which underlies the power of MH
provides all the semantic inspiration needed to cleanly
integrate any new folder access mechanism, IMAP being
but one particularly messy implementation. an implementation
based on "9p", for example, would also plug in the
same way, and with materially less implementation hair.
but that's not an option.

        cheers
        -mo




Joel Reicher wrote:
having IMAP folder names be "different" would be a Kosmik Lose(tm)
the only reason to do IMAP would be because it's transparent.

Every GUI for IMAP that I've ever seen presents the remote folders in
a "section" or "subfolder" representing the IMAP account. This permits
mutiple IMAP accounts and local folders.

Namespacing for remote folders is a reality, not a contrivance. Making
them look like "normal" folder names would just be syntactic sugar, IMHO,
but it could probably be done.

Cheers,

        - Joel




reply via email to

[Prev in Thread] Current Thread [Next in Thread]