Thanks, John. I presume your sending this directly to me and not to
nmh-workers was an accident, as no doubt lots of people would be interested
in the expanded description of your nmh/IMAP plans.
John Reinhagen <[EMAIL PROTECTED]> writes:
> 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.)"
-----------------------------------------------------------------------
Dan Harkless | To prevent SPAM contamination, please
[EMAIL PROTECTED] | do not post this private email address
SpeedGate Communications, Inc. | to the USENET or WWW. Thank you.
