nmh-workers
[Top] [All Lists]

Re: [Nmh-workers] What is MH ?

2006-01-11 11:29:09
... 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
=---------------------
 paul fox, pgf(_at_)foxharp(_dot_)boston(_dot_)ma(_dot_)us (arlington, ma, 
where it's 39.0 degrees)


_______________________________________________
Nmh-workers mailing list
Nmh-workers(_at_)nongnu(_dot_)org
http://lists.nongnu.org/mailman/listinfo/nmh-workers

<Prev in Thread] Current Thread [Next in Thread>