After incorporating input from Andreas and Graham and thinking some
more about this, here's what I'd like to do:
If there are no objections, I'd like to upload Mail::TieFolder and
Mail::Tiefolder::mh to PAUSE sometime in the next few days. The code
runs clean right now (43 regression tests...) ;-)
Name DSLI Description Info
--------------- ---- -------------------------------------------- -----
Mail::TieFolder adpr mail folder tied hash, keyed by Message-ID STEVEGT
Graham Barr <[EMAIL PROTECTED]> wrote:
> On Sun, Nov 12, 2000 at 02:49:11PM -0800, Steve Traugott wrote:
> > Other thoughts about this... What I'd really like to do is start
> > Mail::Tie::* as a tree of similarly tied interfaces to common
> > mailboxes -- i.e. Mail::Tie::mbox, Mail::Tie::IMAP, etc. The only
> > drawback I can see is that that might give people the impression that
> > I "own" Mail::Tie::*, when in fact I'd like nothing more than to
> > encourage others to add to the tree.
>
> Have you taken a look at Mail::Folder which attempts to give a uniform
> interface to many types of mailbox.
Actually, I did look at Mail::Folder earlier. After Graham prompted
me I went back and took another look, and realized there was something
there that I really liked: Kevin did a good job of describing
stylistic and HOWTO guidelines for implementing additional folder
formats under Mail::Folder. This convinced me that it should be
possible to provide a similar level of high-quality encouragement and
handholding for potential authors of Mail::TieFolder::* modules.
Before starting work on Mail::TieFolder, I originally took a look at
trying to use Mail::Folder, as well as Mail::MsgStore. The
Mail::MsgStore docs say:
The Mail::Folder module, on top of not quite being complete yet, is a
pretty low-level API. I was very impressed with how Win32::TieRegistry
simplified an otherwise complex task...
I happen to agree. I can't really build on top of Mail::MsgStore
either though -- it's locked into its own maildir-derived folder
format -- it's not intended to be a universal interface to existing
folders.
One thing I like about tie() interfaces is the fact that they
constrain authors to a reasonably small and well-defined interface --
it's bloatware protection. This protects me from letting my own
imagination run too wild, and it (hopefully) lowers the bar of entry
for later authors who might want to add Mail::TieFolder::* modules to
support additional folder formats.
There are scope and complexity issues I see with Mail::Folder's
current interface which would deter me from trying to implement
Mail::Folder::MH. I won't go into them any more than that here,
because I think that Kevin deserves the benefit of the doubt -- he's
never claimed Mail::Folder is anything but alpha code. While it's
been 32 months since he uploaded the most recent version, I have some
old scraggly stuff floating around the net that I'd like to finish
too, someday. I'd hope nobody beats me up for it in the meantime. ;-)
Perhaps more important (to me) is the fact that Mail::Folder uses
message sequence numbers as the primary key into a folder. There is a
better way (I think), because message sequence numbers are not fixed
attributes uniquely attached to one and only one message. Using
message sequence number for mail is equivalent to using queue position
as the unique identifier for shoppers standing in line at the grocery
-- if you blink, everyone's identity changes. ;-)
The "better way" I wanted to try was to use Message-ID, since it's
theoretically a globally unique identifier. I used it in
Mail::TieFolder as the key into a mail folder. This way I can sort,
renumber, pack, and so on, and still have safe, immutable, persistent
handles on individual messages.
Steve
