In message <[EMAIL PROTECTED]>, also sprach "Dan
Harkless":

>The last time I remember IMAP support coming up was quite awhile ago, and
>the commentary (from Richard Coleman??) was that IMAP support probably
>wouldn't be forthcoming because IMAP would probably spell the eventual death
>of [n]mh.  I don't recall a lot of posts disagreeing with that view, though
>I suspect if the subject were brought up again people would disagree.

I certainly would.  My guess is that Richard Coleman thought of MH's
existing mapping between folders and directories/messages and text files to
be a central feature.  While that is a convenient way to deal with local
storage, it doesn't seem central to me.  To me, the central feature of [n]mh
is that it does away with the monolithic mail client environment in favor of
command- and script-driven environments, and IMAP support wouldn't
compromise this.  (I admit that this reverses my position as stated on
comp.mail.mh.)

>> If not, is there any objection to a Mail::NMH Perl package that provided
>> such a capability via extension?
>
>I don't quite understand the relation between nmh and your proposed Perl
>package, but I'm sure there'd be no objections to any useful extensions to
>nmh.

I'll explain in better detail.  I intend to implement various nmh entities
-- folders, messages, context (including sequences), profile -- as Perl
objects.  Any Perl-aware front end could then use and manipulate those
objects, and one could write a good mail client using such an approach.  (A
GTK-Perl nmh client would be a nice thing to have.)

Thanks to OO, I can specify a storage class for each instance of a {Folder,
Message, Sequence} object, and I can make calls to that storage class to
fetch, move, etc., the object.  Thus, local objects get treated like classic
nmh entities, while IMAP objects implement the same functionality through other
means.

The advantage of this approach is that it doesn't depend on nmh support for
IMAP.  The disadvantage is that it might discourage the implementation of
such support unless some Perl-hater was motivated to correct the
situation...but then they'd probably just implement the same objects in
Python/Java/C++/whatever.  nmh would not likely get IMAP support either way.

If there's an existing intention to put IMAP support in nmh, I'll hold off
on putting it in my Perl objects; I'd really rather handle it all through
nmh anyway.  However, if that's not likely to happen, I will design the
objects to make this possible, and will implement it as time permits.

JCR
--
Observed by Jeff Cooper:
"Headline in the _Arizona Republic_:
        247 POUNDS OF COCAINE SEIZED:  TWO HELD
 (Cheap!  Ten percent is little enough.)"

Reply via email to