Re: [nimh-dev] TODO

["Jon Stewart" <stew1@xxxxxxxxxxx>]

> 1. Make a TODO file.


Are you guys interested in using a bug/issue-tracking system (e.g. 
Bugzilla, scarab)?


> 2. Proposed augmentations for mhlib:
>   a. mhlib should read the environment variables described in mh-profile(5)
>   b. mhlib should handle sequences it does not yet handle
>   c. any others?


I think correct handling of sequences is the major feature. Perhaps it 
would be cool to expose the IntSet representation of the sequence, but 
only if someone complains about nimh not being able to handle a million 
messages in a folder when run on a 486 with 16MB RAM.


> 3. Decide what to do about mh-format: keep? toss?
>   If toss:
>     Maybe we want to define, e.g., a 'scanformatproc' key, which just
>     feeds the raw data to some program, which then hands its output back to
>     scan. That way, I could write my scan format in python or sed or perl or
>     cat it from /dev/random, and I could make it as (un)readable as I choose.
>   Maybe mhlib should understand mh-formats too?


I think mh-format is baroquen. I like the idea of calling an external 
program, if specified, or calling a specified python module (then you have 
access to the object model, which is cool). If not, things like scan 
should perform the default behavior themselves. Maybe at some point we can 
attract an old mh hand to write a parser/converter, but I don't have much 
invested in their weird-ass formatting language and I'd prefer not to have 
to understand it.

Besides, the de-coupled approach is more powerful. You could write a 
webmail backend using it, or half of a GUI.


Jon
-- 
Jon Stewart                                 Advanced Los Angeles C++
stew1@xxxxxxxxxxx                           http://www.alacpp.org
_______________________________________________
nimh-dev mailing list
nimh-dev@xxxxxxxxxxx
http://lists.ellipsis.cx/mailman/listinfo/nimh-dev