[Top][All Lists]

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

Re: [Nmh-workers] What is MH ?

From: Paul Fox
Subject: Re: [Nmh-workers] What is MH ?
Date: Wed, 11 Jan 2006 10:50:27 -0500

 > ... it keeps being asked why anyone would object to adding
 > some code, after all, everything that's there now would still
 > work, right?  And one assume that the new code would be
 > conditionally compiled, so it need not even necessarily make
 > the binaries any bigger or slower for those who don't need it. 
 > There are two things overlooked by this however - first
 > anything like this (especially anything this big) tends to
 > make the sources just that much more unmanageable, which can
 > become a problem of its own.  But even more important, once
 > done, new "features" like this tend to become a road block to
 > other progress, other things can't get done, or can't be done

thanks for summarizing what i've been thinking on this topic.  i
think the last thing we'd want to do is add more features within
mh.  if anything, i'd rather start looking at mh with an eye
towards pruning -- of obsolete architecture support, or of
minimally useful features, or of things that can be readily done
external to mh.  all in the interests of increasing maintainability.

but the flip side of the imap issue is this -- at least for me: 
is the IMAP protocol and folder model really rich enough to make
it representable as a filesystem?  at least, as a filesystem
which would be useful for mh's purposes?  obviously "cat", "mv",
"rm" kinds of things can be done, and with caching i suppose
searching (i.e., "grep foobar $(mhpath first-last)" kinds of
things) could be made efficient, but presumably hard-linking
("refile -link") would go by the wayside.

so, how complete a filesystem could be done with imap?

 paul fox, address@hidden (arlington, ma, where it's 39.0 degrees)

reply via email to

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