"Lyndon Nerenberg (VE6BBM/VE7TFX)" writes:
> > I have spent a lot of time
> > trying to understand what multistore semantics might mean. IMAP maps
> > quite naturally to the native MH store, and MH itself naturally fits
> > the IMAP offline client model. Could this be extended to encompass
> > mo
jon wrote:
> > ve6bbm/ve7tfx wrote:
> > > Another concern is meta-data. MH annotates messages by adding headers
> > > to the message file. Messages in IMAP are immutable, so that won't
> >
> > i don't think i was aware of this. i don't recall MH ever modifying
> > a message, and would h
> ve6bbm/ve7tfx wrote:
> > Another concern is meta-data. MH annotates messages by adding headers
> > to the message file. Messages in IMAP are immutable, so that won't
>
> i don't think i was aware of this. i don't recall MH ever modifying
> a message, and would have claimed that it doesn't d
> i don't think i was aware of this. i don't recall MH ever modifying
> a message, and would have claimed that it doesn't do so. i assume
> it's part of a feature i've never used?
>From repl(1):
If the -annotate switch is given, the message being replied-to will be
annotated with
ve6bbm/ve7tfx wrote:
> Another concern is meta-data. MH annotates messages by adding headers
> to the message file. Messages in IMAP are immutable, so that won't
i don't think i was aware of this. i don't recall MH ever modifying
a message, and would have claimed that it doesn't do so. i ass
> I have spent a lot of time
> trying to understand what multistore semantics might mean. IMAP maps
> quite naturally to the native MH store, and MH itself naturally fits
> the IMAP offline client model. Could this be extended to encompass
> more alien message stores, such as Exchange?
I didn't
> I have no religious objection to a native IMAP
> implementation; I would actually like that to happen.
In a general sense it is worth investigating whether MH can be
extended to use more than the traditional message store, without
breaking its long-standing semantics. I have spent a lot of time
>I twisted up a crude proof-of-concept implementation about 10 years
>ago. I did it solely to get an idea of how much work it would be to
>do a full-on implementation. This was against MH 6.3, and done while
>I was considering giving 6.3 a complete overhaul to ANSIfy the code
>and clean out all t
> ARE you working on IMAP for nmh? If so, how far are
> you along?
I twisted up a crude proof-of-concept implementation about 10 years
ago. I did it solely to get an idea of how much work it would be to
do a full-on implementation. This was against MH 6.3, and done while
I was considering givi
>> Unless, Lyndon, _you_
>> are volunteering to implement IMAP for nmh the "right" way. Are you? No?
>> Didn't think so.
>
>How could you possibly know what I am or am not working on?
Well, I'm basing my guess on years of people doing no visible work on
IMAP for nmh (that includes me as well, of
> Unless, Lyndon, _you_
> are volunteering to implement IMAP for nmh the "right" way. Are you? No?
> Didn't think so.
How could you possibly know what I am or am not working on?
___
Nmh-workers mailing list
Nmh-workers@nongnu.org
http://lists.nongnu
Thus spake Ken Hornstein:
>
> While I don't disagree with you, we have to face facts here.
>
> The sad truth is that MH/nmh development effort has been ... well, I guess
> the kindest way to say it is "lacking" lately. And by "lately", you could
> measure that timespan in years. The basic probl
>Fuse is a major step forward for UNIX-like systems. But Fuse can
>never be as portable as a conforming POSIX application. MH has always
>been able to compile on anything even remotely resembling UNIX. Tying
>it to a very implementation-specific API like this would negate nearly
>30 years of por
13 matches
Mail list logo
