Re: [Nmh-workers] nmh in near, medium, and far-term
Definitely agree on ditching MM_CHARSET and enabling MIME code regardless of any locale settings. MH-E developers: please rack your brains and the SourceForge trackers for changes to MH that would benefit MH-E. Thanks! Ken Hornstein k...@pobox.com writes: Okay, the recent messages about nmh have driven me to write this email, but it's been brewing for a while now. Maybe just getting back from the Happiest Place On Earth helped. Here are my thoughts about what we should be doing with nmh in the near, medium, and long(er) term. In all of these cases, I am proposing that I do this work. I am interested in hearing what people think about this. - Near term - release, damn it! This is driven by the fact that my wife got a new machine at work, and was giving me a hard time about the fact that getting a new copy of nmh on it was a pain. Okay, this is kind of embarassing. Having to fetch the sources out of git to get a new release is embarassing. I propose just taking the current HEAD and making it nmh 1.4. Also putting a package into MacPorts would be nice. - Medium term - packaging, Autoconf/Automake cleanup As I discussed in previous email, we should do better with packaging. Shipping a spec file with nmh would make sense; other packages do this, why not us? Also it would be nice to clean up our Autoconf/Automake setup, which is ... not as elegant as it could be. - Long term - better MIME/charset handling Specifically, scan can decode RFC 2047 headers, but it seems that show cannot (okay, mhshow seems to decode some headers, but not others). Also, the whole replying to messages that are quoted-printable or even base64 encoded ... what a mess. I am thinking of making the nmh libraries convert all message data upon read into Unicode (specifically UTF-8, but I'd be open to other ideas), and then converting/encoding it as needed upon output. I am _not_ thinking of changing the on-disk format; inc will still write the original email as received to disk. These changes would happen to show friends. But this would allow us to do a lot saner things with messages that are quoted-printable or base64 encoded (which are more and more of them, unfortunately). If you had a UTF-8 based locale, your life would be a lot happier (I'd also ditch MM_CHARSET, since that seems to be nmh-specific and I see no reason to keep it around). Now there are a billion and one things to think about here and I haven't looked at the code to see how feasible any of this is; that's why it's marked under long term. Anyway, that's what I'm thinking about. I'm open to other suggestions, but please only send them in if you're going to write them (or pay me to write them :-) ). --Ken ___ Nmh-workers mailing list Nmh-workers@nongnu.org https://lists.nongnu.org/mailman/listinfo/nmh-workers -- Bill Wohler woh...@newt.com aka bill.woh...@nasa.gov http://www.newt.com/wohler/ GnuPG ID:610BD9AD ___ Nmh-workers mailing list Nmh-workers@nongnu.org https://lists.nongnu.org/mailman/listinfo/nmh-workers
Re: [Nmh-workers] nmh in near, medium, and far-term
On 2011-12-12, at 2:03 AM, Ken Hornstein wrote: Yeah, I think we're all on the same page here. I'm all in favor of reducing our #ifdef mess. I'm on the road for the next week and a bit, but as soon as I get back I'll push my POSIX work onto the working branch I created. It's not complete yet, but it's a fair ways along the path of getting rid of a lot of that cruft. ___ Nmh-workers mailing list Nmh-workers@nongnu.org https://lists.nongnu.org/mailman/listinfo/nmh-workers
Re: [Nmh-workers] nmh in near, medium, and far-term
David Levine levin...@acm.org writes:
I'm also wary of changing the message file naming scheme.
anno modifies messages, so it is inconsistent with a naming
scheme that includes file size, hash, or other properties.
I could probably live without anno, but someone else might
consider it important.
Me, for example, which is why my suggested change to naming
scheme is /almost/ something you can do in mh already by
automatically filing messages in (say) +Accessions/${date +%s}
(something would have to create such a folder for each inc) and
refile -link each new message into +inbox (or wherever it would
normally go).
The trouble with that is that while one could then incrementally
archive the Accessions folders, incremental archival of the
contents of the other folders would either duplicate the content
of message files or require a (potentially costly) search to
determine which file in the Accessions folders should be linked
to. Perhaps all I want is a -symlink option for refile and a
guarantee that all mh progs can be told to treat symlinked
messages as if they were linked?
--
Jón Fairbairn jon.fairba...@cl.cam.ac.uk
___
Nmh-workers mailing list
Nmh-workers@nongnu.org
https://lists.nongnu.org/mailman/listinfo/nmh-workers
Re: [Nmh-workers] nmh in near, medium, and far-term
Valdis Kletnieks: Unfortunately, for signed mails, it's quite often the case that you will need to re-verify the signature at a later date. If 6 months later you need to produce the mail your boss sent, you're probably going to want to be able to reproduce the signature too. Actually, let me take that a step further - you *always* need to be able to deal with the usage case Hey, let me forward you the note that Fred sent me last month on this - it has everything you need attached. Which means you need to either keep Fred's actual message around, or enough information to regenerate the message. And if Fred included a digital signature or encryption, then you need to be able to cope with that as well. OK, I agree. I was never in such a situation, but I get your point. ___ Nmh-workers mailing list Nmh-workers@nongnu.org https://lists.nongnu.org/mailman/listinfo/nmh-workers
Re: [Nmh-workers] nmh in near, medium, and far-term
On Sun, 11 Dec 2011 10:36:15 GMT, Jon Fairbairn said: to. Perhaps all I want is a -symlink option for refile and a guarantee that all mh progs can be told to treat symlinked messages as if they were linked? OK, that raises a good question - if we're doing an overhaul of the code, what system(s) do we want it to run on? I seem to recall that there's a number of places in the code where mh does some incredibly bizarre tap-dancing to deal with the fact that some systems didn't have proper symlinks. I'm *not* going to go as far as saying make it work on Linux only and take advantage of features - but if there's support for ancient systems in there that we can heave overboard to make the code simpler we probably should discuss it. Anybody got a straw-man list of features/systems they think are deceased and can be tossed? pgpBnfThVT3sz.pgp Description: PGP signature ___ Nmh-workers mailing list Nmh-workers@nongnu.org https://lists.nongnu.org/mailman/listinfo/nmh-workers
Re: [Nmh-workers] nmh in near, medium, and far-term
Jon Fairbairn writes: The idea makes me wonder if git could be used as a mailstore. With a blob for each message and tag-blobs for classifying messages. Could be nice if you can push and pull mail between machines. That does have a certain appeal. It's something I've been thinking about for several years: http://lists.nongnu.org/archive/html/nmh-workers/2008-05/msg00048.html However, like everything else in my life, I just don't seem to have had the time to get around to doing anything about it :-( Tet ___ Nmh-workers mailing list Nmh-workers@nongnu.org https://lists.nongnu.org/mailman/listinfo/nmh-workers
Re: [Nmh-workers] nmh in near, medium, and far-term
I personally would like to see nmh declared end-of-life for non-UNIX-like systems. There's a lot of cruft in the code from these days the understanding of which is a barrier to getting new work done. I see a lot of stuff in there for older UNIX systems, but I'm trying to think of examples for non-UNIX systems; could you provide some examples? --Ken ___ Nmh-workers mailing list Nmh-workers@nongnu.org https://lists.nongnu.org/mailman/listinfo/nmh-workers
Re: [Nmh-workers] nmh in near, medium, and far-term
On Sun, 11 Dec 2011 19:20:10 EST, Ken Hornstein said: I personally would like to see nmh declared end-of-life for non-UNIX-like systems. There's a lot of cruft in the code from these days the understandng of which is a barrier to getting new work done. I see a lot of stuff in there for older UNIX systems, but I'm trying to think of examples for non-UNIX systems; could you provide some examples? I'd make the case that SunOS 4.1 from 25 years ago (still mentioned in the MACHINES file) is sufficiently remote from today's definition to qualify as non-UNIX-like ;) pgp2nbjLsqH7p.pgp Description: PGP signature ___ Nmh-workers mailing list Nmh-workers@nongnu.org https://lists.nongnu.org/mailman/listinfo/nmh-workers
Re: [Nmh-workers] nmh in near, medium, and far-term
--===6840960053006057842== Content-Type: multipart/signed; boundary===_Exmh_1323651731_10493P; micalg=pgp-sha1; protocol=application/pgp-signature Content-Transfer-Encoding: 7bit --==_Exmh_1323651731_10493P Content-Type: text/plain; charset=us-ascii On Sun, 11 Dec 2011 19:20:10 EST, Ken Hornstein said: I personally would like to see nmh declared end-of-life for non-UNIX-like systems. There's a lot of cruft in the code from these days the understandng of which is a barrier to getting new work done. I see a lot of stuff in there for older UNIX systems, but I'm trying to think of examples for non-UNIX systems; could you provide some examples? I'd make the case that SunOS 4.1 from 25 years ago (still mentioned in the MACHINES file) is sufficiently remote from today's definition to qualify as non-UNIX-like ;) Yes, this is what I had in mind Mind you, I still have one of those systems in the store room, but would be happy to use an old version of nmh on it if I ever had to turn it on. Jon ___ Nmh-workers mailing list Nmh-workers@nongnu.org https://lists.nongnu.org/mailman/listinfo/nmh-workers
Re: [Nmh-workers] nmh in near, medium, and far-term
I'd make the case that SunOS 4.1 from 25 years ago (still mentioned in the MACHINES file) is sufficiently remote from today's definition to qualify as non-UNIX-like ;) Yeah, I think we're all on the same page here. I'm all in favor of reducing our #ifdef mess. --Ken ___ Nmh-workers mailing list Nmh-workers@nongnu.org https://lists.nongnu.org/mailman/listinfo/nmh-workers
Re: [Nmh-workers] nmh in near, medium, and far-term
Earl Hood: On Fri, Dec 9, 2011 at 9:29 PM, Ken Hornstein k...@pobox.com wrote: I thought about breaking up the MIME parts, but I decided that the problem with that was that I believe there is value to still having the original message around. Just think of SMIME, PGP, DKIM, et.al. Preserving the original message is handy whenever one needs to (re)verify the message that are signed or encrypted. I disagree, one should break up the MIME parts. There is not value in keeping MIME beasts in your file system. If it's encrypted MIME there should be a command that decrypts and detangles mails. Why store a mail encrypted on your encrypted hard drive, I always decrypt and verify my mails only once. I would love this, obscure mails arrive and the system converts them into what I prefer - separate files, all text utf8 and so on ... ;-) Best regards, Yoshi ___ Nmh-workers mailing list Nmh-workers@nongnu.org https://lists.nongnu.org/mailman/listinfo/nmh-workers
Re: [Nmh-workers] nmh in near, medium, and far-term
Hi Yoshi, I thought about breaking up the MIME parts, but I decided that the problem with that was that I believe there is value to still having the original message around. You're right, there is. In regurgitating long ago thoughts I ommitted that bit. It could be available under a path that was easily excluded at the command line. for what do you guys need original MIME mails? Investigating problems; what did nmh receive? Sending them on with dist(1). I expect there are others, like the signature-checking mentioned earlier. Cheers, Ralph. ___ Nmh-workers mailing list Nmh-workers@nongnu.org https://lists.nongnu.org/mailman/listinfo/nmh-workers
Re: [Nmh-workers] nmh in near, medium, and far-term
I'm more sure about the other two: dist(1) could recreate a mime mail, since we need that mime-creation functionality anyways. And as stated before I think one should verify a mail only once. The first time you show(1) a PGP/MIME mail it (asks for the password and decrypts and) tries to verify the mail. (not a valid signature: delete or keep) Ouch, the mail gets stored _unencrypted_? I think that's a terrible idea. I'd be okay with adding code that did that, but I would never support making that default behavior. One-time signature verification, that is okay. Regarding the other ideas about changing the back-end storage of messages; I _myself_ am not interested in writing that code. If someone else wants to write that code, I would be supportive of adding it to nmh (but we'd have to think about compatibility, etc etc). So have at it, gentlemen! --Ken ___ Nmh-workers mailing list Nmh-workers@nongnu.org https://lists.nongnu.org/mailman/listinfo/nmh-workers
Re: [Nmh-workers] nmh in near, medium, and far-term
On Sat, 10 Dec 2011 12:27:00 +0100, Yoshi Rokuko said: I disagree, one should break up the MIME parts. There is not value in keeping MIME beasts in your file system. If it's encrypted MIME there should be a command that decrypts and detangles mails. Why store a mail encrypted on your encrypted hard drive, I always decrypt and verify my mails only once. Just because decrypt and verify my mails only once is a workable scheme for you, doesn't mean it's the *only* way. Unfortunately, for signed mails, it's quite often the case that you will need to re-verify the signature at a later date. If 6 months later you need to produce the mail your boss sent, you're probably going to want to be able to reproduce the signature too. And note that you're making the assumption that the person has access to an encrypted hard drive with the proper security characteristics, which may not necessarily be the case. (And yes, not all encrypted hard drives are created equal - just because a given encryption scheme is appropriate for most of your work, doesn't mean it's appropriate for sensitive data). pgpvDECyIhdoB.pgp Description: PGP signature ___ Nmh-workers mailing list Nmh-workers@nongnu.org https://lists.nongnu.org/mailman/listinfo/nmh-workers
Re: [Nmh-workers] nmh in near, medium, and far-term
On Sat, 10 Dec 2011 20:56:44 EST, valdis.kletni...@vt.edu said: Unfortunately, for signed mails, it's quite often the case that you will need to re-verify the signature at a later date. If 6 months later you need to produce the mail your boss sent, you're probably going to want to be able to reproduce the signature too. Actually, let me take that a step further - you *always* need to be able to deal with the usage case Hey, let me forward you the note that Fred sent me last month on this - it has everything you need attached. Which means you need to either keep Fred's actual message around, or enough information to regenerate the message. And if Fred included a digital signature or encryption, then you need to be able to cope with that as well. pgpMkVADLQ6Ek.pgp Description: PGP signature ___ Nmh-workers mailing list Nmh-workers@nongnu.org https://lists.nongnu.org/mailman/listinfo/nmh-workers
Re: [Nmh-workers] nmh in near, medium, and far-term
Jon Fairbairn wrote: Long ago, before mh I used an email system that stored email in files with unique ids, which suggests a way to do this. Switch to storing messages in (say) date-named accession order folders with unique filenames (derived from the message-id, or simply accession numbers) while the mh folders would contain symlinks to these with numeric names as now. So (to continue the example) sortm would not rename any message files, but just rearrange the symlinks. If you're going to do that, you might aswell name the files using an SHA hash. It's not like mail files change often. The idea makes me wonder if git could be used as a mailstore. With a blob for each message and tag-blobs for classifying messages. Could be nice if you can push and pull mail between machines. Oliver ___ Nmh-workers mailing list Nmh-workers@nongnu.org https://lists.nongnu.org/mailman/listinfo/nmh-workers
Re: [Nmh-workers] nmh in near, medium, and far-term
On 12/9/2011 11:13 PM, Oliver Kiddle wrote: Jon Fairbairn wrote: Long ago, before mh I used an email system that stored email in files with unique ids, which suggests a way to do this. Switch to storing messages in (say) date-named accession order folders with unique filenames (derived from the message-id, or simply accession numbers) while the mh folders would contain symlinks to these with numeric names as now. So (to continue the example) sortm would not rename any message files, but just rearrange the symlinks. If you're going to do that, you might aswell name the files using an SHA hash. It's not like mail files change often. The idea makes me wonder if git could be used as a mailstore. With a blob for each message and tag-blobs for classifying messages. Could be nice if you can push and pull mail between machines. i actually like the idea of putting useful information into the filename, like the file size with and without CRLF translation, since it lets us learn things from readdir() without having to call fstat(). not that we couldn't add a hash of some kind if we need it for uniqueness, but i don't think we will. ___ Nmh-workers mailing list Nmh-workers@nongnu.org https://lists.nongnu.org/mailman/listinfo/nmh-workers
Re: [Nmh-workers] nmh in near, medium, and far-term
On Fri, Dec 9, 2011 at 18:13, Oliver Kiddle okid...@yahoo.co.uk wrote: Jon Fairbairn wrote: Long ago, before mh I used an email system that stored email in files with unique ids, which suggests a way to do this. Switch to storing messages in (say) date-named accession order folders with unique filenames (derived from the message-id, or simply accession numbers) while the mh folders would contain symlinks to these with numeric names as now. So (to continue the example) sortm would not rename any message files, but just rearrange the symlinks. If you're going to do that, you might aswell name the files using an SHA hash. It's not like mail files change often. The idea makes me wonder if git could be used as a mailstore. With a blob for each message and tag-blobs for classifying messages. Could be nice if you can push and pull mail between machines. I don't know whether to say great minds think alike, or that you are sick. Because I had similar thoughts this morning... One thing I would like to add, is if that we are going to build an index, it would be really handy to include the Message-ID in an index. This would make it very easy for front-ends to thread e-mail, follow references, etc. I have my fetchmail scripts ignore messages with a duplicate messageid (using a history of messageids I've received during the last 30 days or so) to avoid duplicate mail. It is probably too much to assume that everyone would not have duplicate copies of a message with the same messageid. Some people may have valid reasons for this. And there may be messages w/o a message-id. Thanks Jeff -- Jeffrey C. Honig j...@honig.net http://www.honig.net/jch GnuPG ID:14E29E13 http://www.honig.net/jch/key.shtml ___ Nmh-workers mailing list Nmh-workers@nongnu.org https://lists.nongnu.org/mailman/listinfo/nmh-workers
Re: [Nmh-workers] nmh in near, medium, and far-term
On Fri, Dec 9, 2011 at 5:25 PM, Jeffrey Honig j...@honig.net wrote: I have my fetchmail scripts ignore messages with a duplicate messageid (using a history of messageids I've received during the last 30 days or so) to avoid duplicate mail. Depends on what you mean by duplicate. From a mail archiving perspective, you can have multiple messages with same message ID, but can be considered different messages, even if the content is the same. Example: Mail that is sent to individuals and mailing list(s). Mailing lists typically add additional headers (e.g. List-*) and custom footers, so the message that is received by list subscribers is not identical to versions received directly from the original sender. It is probably too much to assume that everyone would not have duplicate copies of a message with the same messageid. Some people may have valid reasons for this. Archiving messages to mailing lists is a valid reason. And there may be messages w/o a message-id. This is the case for draft messages in nmh. --ewh ___ Nmh-workers mailing list Nmh-workers@nongnu.org https://lists.nongnu.org/mailman/listinfo/nmh-workers
Re: [Nmh-workers] nmh in near, medium, and far-term
Hi, Oliver Kiddle wrote: If you're going to do that, you might aswell name the files using an SHA hash. Thoughts I've had over the years... MH was handy because it integrated with the Unix command line and filesystem; I still awk, etc., ~/mail/inbox/* on occasion when nmh's commands don't suffice. That's good; I don't think nmh should grow every bell and whistle. MIME breaks this. If all textual parts were stored in UTF-8 on disk things would improve once again. Perhaps even a mail/inbox/42 for a UTF-8 summary of the email, headers and the body laid out as text where possible, and a mail/inbox/42/... with the headers and each part as a separate file, including sub-directories where needed, e.g. ~/mail/inbox/42/foo.png exists. Plan 9 had something along these lines. http://plan9.bell-labs.com/magic/man2html/4/upasfs The other thing would be a single name for the email with links implementing folders/tags. That backups think a lot has changed when a folder is packed is a flaw. Possibly in the backup software, I'll admit. I don't see these fitting easily into nmh but thought I'd throw them out there whilst there's list activity. :-) Cheers, Ralph. ___ Nmh-workers mailing list Nmh-workers@nongnu.org https://lists.nongnu.org/mailman/listinfo/nmh-workers
Re: [Nmh-workers] nmh in near, medium, and far-term
We are getting dangerously close to an observation i've made a few times recently, which is that We've discovered Metadata! moreover, the metadata about a file is now as important as the data. We've poked and futzed with where to store metadata for files, though I think hide is a better term, and have converged (painfully) on storing general (key,value) tupes. The obvious head-slap is that the data is just the value in one more tuple with a well-known key like filecontents. So there is no longer any data, only metadata! so what was a file is now a directory or a map or a hash depending on your first or favorite programming language. i note ruefully that MacOS10 files had a data fork for the bits we know and love and a resource fork (which stored the key-value pairs) what we really need is Plan 9 user filesystems so we could just mount an MH-friendly view on top of a store more suited to the moderne world. unfortunately, we don't got that yet. however, note that the Kthings and the Gthings desktops all go through libraries that allow the apps to take URLs where apps would previously demand a filename. maybe there's a way to reskin this skinless directory tree? i will mention the old, ugly, disgusting, but damn powerful hack which has saved the communal bacon more than a few times before: replace libc or rather, intercept read(), write(), open(), close(), creat(), unlink(), etc... This saved Netnews, UUCP, Sendmail, and UUNET's original accounting system written in AWK, some more than once. I just realized that with FUZE i guess we could go to the extreme of a view filesystem if we felt compelled. It's ironically amusing that one of the oldest non-original UNIX apps I still use day-in and day-out is pushing this issue hard. Abstract semantics vs implementation semantics: who wins? who should win? As John Day says in his great book on network architecture, The problem with *reductio ad absurdum* is knowing when to stop! and on that bombshell, we have to end. GOODNIGHT! (cue ending theme) -mo On 12/9/11 7:43 PM, Ralph Corderoy wrote: Hi, Oliver Kiddle wrote: If you're going to do that, you might aswell name the files using an SHA hash. Thoughts I've had over the years... MH was handy because it integrated with the Unix command line and filesystem; I still awk, etc., ~/mail/inbox/* on occasion when nmh's commands don't suffice. That's good; I don't think nmh should grow every bell and whistle. MIME breaks this. If all textual parts were stored in UTF-8 on disk things would improve once again. Perhaps even a mail/inbox/42 for a UTF-8 summary of the email, headers and the body laid out as text where possible, and a mail/inbox/42/... with the headers and each part as a separate file, including sub-directories where needed, e.g. ~/mail/inbox/42/foo.png exists. Plan 9 had something along these lines. http://plan9.bell-labs.com/magic/man2html/4/upasfs The other thing would be a single name for the email with links implementing folders/tags. That backups think a lot has changed when a folder is packed is a flaw. Possibly in the backup software, I'll admit. I don't see these fitting easily into nmh but thought I'd throw them out there whilst there's list activity. :-) Cheers, Ralph. ___ Nmh-workers mailing list Nmh-workers@nongnu.org https://lists.nongnu.org/mailman/listinfo/nmh-workers ___ Nmh-workers mailing list Nmh-workers@nongnu.org https://lists.nongnu.org/mailman/listinfo/nmh-workers
Re: [Nmh-workers] nmh in near, medium, and far-term
On Fri, Dec 9, 2011 at 18:58, Earl Hood e...@earlhood.com wrote: On Fri, Dec 9, 2011 at 5:25 PM, Jeffrey Honig j...@honig.net wrote: I have my fetchmail scripts ignore messages with a duplicate messageid (using a history of messageids I've received during the last 30 days or so) to avoid duplicate mail. Depends on what you mean by duplicate. From a mail archiving perspective, you can have multiple messages with same message ID, but can be considered different messages, even if the content is the same. Example: Mail that is sent to individuals and mailing list(s). Mailing lists typically add additional headers (e.g. List-*) and custom footers, so the message that is received by list subscribers is not identical to versions received directly from the original sender. If the content is the same, they are the same message and would be duplicate. A message identifier identifies exactly one instantiation of a message. The changes you describe must not change the the content of the message, or a new Message-ID would need to be generated (see RFC2822 3.6.4). When I send a message to a mailing list, I could get it back with some more headers and footer, or I might not get it back because I do not subscribe to that mailing list, or do not receive copies of my own posts. I believe that the list of where it has been and what ads the mailing list host adds are irrelevent.. Someone may redist said message to another mailing list, or it may go through a gateway to a news group and back to another mailing list. I wouldn't even see that information so do not feel that archiving duplicate copies of a message with different transport information is necessary. There are valid reasons to keep messages with duplicate IDs, such as your example below. My point is that we should allow for duplicate Message-Ids if we implemented a Message-Id index. It is probably too much to assume that everyone would not have duplicate copies of a message with the same messageid. Some people may have valid reasons for this. Archiving messages to mailing lists is a valid reason. And there may be messages w/o a message-id. This is the case for draft messages in nmh. As an anecdote, I was not seeing some e-mail replies from my boss. I tracked it down to the Good (tm) e-mail client he was using. It would not generate a new message-id on a Reply. Thankfully they fixed it in a later update before I missed something important. Thanks Jeff -- Jeffrey C. Honig j...@honig.net http://www.honig.net/jch GnuPG ID:14E29E13 http://www.honig.net/jch/key.shtml ___ Nmh-workers mailing list Nmh-workers@nongnu.org https://lists.nongnu.org/mailman/listinfo/nmh-workers
Re: [Nmh-workers] nmh in near, medium, and far-term
MIME breaks this. If all textual parts were stored in UTF-8 on disk things would improve once again. Perhaps even a mail/inbox/42 for a UTF-8 summary of the email, headers and the body laid out as text where possible, and a mail/inbox/42/... with the headers and each part as a separate file, including sub-directories where needed, e.g. ~/mail/inbox/42/foo.png exists. Plan 9 had something along these lines. http://plan9.bell-labs.com/magic/man2html/4/upasfs I thought about breaking up the MIME parts, but I decided that the problem with that was that I believe there is value to still having the original message around. As for something like upasfs ... well, my answer to that is simple: have at it, my friend! If you want to make a branch on the nmh git repo, be my guest. --Ken ___ Nmh-workers mailing list Nmh-workers@nongnu.org https://lists.nongnu.org/mailman/listinfo/nmh-workers
Re: [Nmh-workers] nmh in near, medium, and far-term
On Fri, Dec 9, 2011 at 9:29 PM, Ken Hornstein k...@pobox.com wrote: I thought about breaking up the MIME parts, but I decided that the problem with that was that I believe there is value to still having the original message around. Just think of SMIME, PGP, DKIM, et.al. Preserving the original message is handy whenever one needs to (re)verify the message that are signed or encrypted. --ewh ___ Nmh-workers mailing list Nmh-workers@nongnu.org https://lists.nongnu.org/mailman/listinfo/nmh-workers
Re: [Nmh-workers] nmh in near, medium, and far-term
Ralph wrote: Thoughts I've had over the years... MH was handy because it integrated with the Unix command line and filesystem; I still awk, etc., ~/mail/inbox/* on occasion when nmh's commands don't suffice. That's good; I don't think nmh should grow every bell and whistle. MIME breaks this. If all textual parts were stored in UTF-8 on disk things would improve once again. I agree. Grep is a requirement for me. I handle repl of MIME messages by decoding base64-encoded text/plain parts. I actually modify the message (using a script). I realize that not everyone wants to do that, but one of the beauties of nmh is that I can. So I am wary of fundamental changes to nmh's message per file approach. Additional files and/or dbs with metadata would be fine. It would be even better to integrate that decoding into nmh, optionally of course, and I would like to do that some day. I'm also wary of changing the message file naming scheme. anno modifies messages, so it is inconsistent with a naming scheme that includes file size, hash, or other properties. I could probably live without anno, but someone else might consider it important. David ___ Nmh-workers mailing list Nmh-workers@nongnu.org https://lists.nongnu.org/mailman/listinfo/nmh-workers
Re: [Nmh-workers] nmh in near, medium, and far-term
Paul Vixie vi...@isc.org writes: dovecot is mapping a thing that does not change (IMAP UID) to another thing that does not change (message file name). therefore they never have to edit or rewrite this file. if MH used a text file then we would have to copy it to mumble.new with changes, and rename it back to mumble, every time a message's message number changed. this seems like it would be harder to implement, as well as slower, than a berkeley db thing (.dir and .pag files). ymmv. I’ve never really liked the fact that mh messages files change their names. For one thing, it makes archiving mail folders relatively messy because (for a particular example) sortm scrambles the relationship between filenames and contents. On the other hand I really like the fact that mh stores messages in plain files, with directories for folders. Long ago, before mh I used an email system that stored email in files with unique ids, which suggests a way to do this. Switch to storing messages in (say) date-named accession order folders with unique filenames (derived from the message-id, or simply accession numbers) while the mh folders would contain symlinks to these with numeric names as now. So (to continue the example) sortm would not rename any message files, but just rearrange the symlinks. That solves the archive problem and means that there is something that doesn’t change to map to IMAP numbers. -- Jón Fairbairn jon.fairba...@cl.cam.ac.uk ___ Nmh-workers mailing list Nmh-workers@nongnu.org https://lists.nongnu.org/mailman/listinfo/nmh-workers
Re: [Nmh-workers] nmh in near, medium, and far-term
On 12/7/2011 3:39 AM, Ken Hornstein wrote: I was thinking that if we want to have something that IMAP already uses to refer to messages that is close to how message numbers work today in exmh, then that would be useful. But you say below that you want something more permament than how message numbers work today in IMAP. sadly, what i want doesn't matter. it's not a pony, by the way, i have several of those. what i want is for mark crispin to define IMAP in terms of how MH worked at that time. lacking as i do a time machine, what i note as ineffable current facts of reality are as follows: 1. IMAP UID's are permanent. neither a IMAP UID nor the header of a message can change once that message has been entered into a folder. so, anno is structurally incompatible with IMAP. and MH message numbers, due to sortm and pack, are incompatibly dissimilar to IMAP UID's. 2. IMAP message numbers are ephemeral, they change every time a message is deleted from the folder. IMAP message numbers are also therefore incompatibly dissimilar to MH message numbers. 3. MH would need to create its own mapping of message number to message file, generating it upon need, regenerating it upon need, or keeping it up to date upon opportunity. Now, as for how Dovecot converts that to a IMAP UID ... does there happen to be a file called dovecot-uidlist somewhere? From what I see that's how the mapping from IMAP UID to filename happens. yes: [ss:amd64] head Maildir/.w.isc/dovecot-uidlist 3 V1307807266 N1 G39749f2dc60a544e417d0100ed0edd69 1 :1307907328.M573701P18883.ss.vix.com,S=4147,W=4247 2 :1313603804.M634412P67456.ss.vix.com,S=31035,W=31486 3 :1313714671.M755710P67456.ss.vix.com,S=2423,W=2481 4 :1314033739.M603759P65995.ss.vix.com,S=1699,W=1753 5 :1314033818.M610134P65995.ss.vix.com,S=1539,W=1580 6 :1314038890.M845459P66764.ss.vix.com,S=8940,W=9167 7 :1314110806.M314157P92665.ss.vix.com,S=3452,W=3535 8 :1314110810.M819206P92665.ss.vix.com,S=4366,W=4469 9 :1314110817.M476028P92665.ss.vix.com,S=2560,W=2613 in fact: [ss:amd64] ls -l Maildir/.w.isc/dovecot* -rw-rw-r-- 1 vixie staff 30 Dec 4 18:54 Maildir/.w.isc/dovecot-keywords -rw-rw-r-- 1 vixie staff 63722 Dec 7 15:13 Maildir/.w.isc/dovecot-uidlist -rw-rw-r-- 1 vixie staff 27608 Dec 5 18:49 Maildir/.w.isc/dovecot.index -rw-rw-r-- 1 vixie staff 912384 Dec 7 17:26 Maildir/.w.isc/dovecot.index.cache -rw-rw-r-- 1 vixie staff5676 Dec 7 15:13 Maildir/.w.isc/dovecot.index.log -rw-rw-r-- 1 vixie staff 32828 Dec 5 18:45 Maildir/.w.isc/dovecot.index.log however, MH need not depend on any of this. we'll just make our own mh.index or whatever. I see that Dovecot seems to use a simple text file; maybe that's good enough for a first-level effort? Or perhaps because it's longer running it's not as much of a performance drag. dovecot is mapping a thing that does not change (IMAP UID) to another thing that does not change (message file name). therefore they never have to edit or rewrite this file. if MH used a text file then we would have to copy it to mumble.new with changes, and rename it back to mumble, every time a message's message number changed. this seems like it would be harder to implement, as well as slower, than a berkeley db thing (.dir and .pag files). ymmv. paul ___ Nmh-workers mailing list Nmh-workers@nongnu.org https://lists.nongnu.org/mailman/listinfo/nmh-workers
Re: [Nmh-workers] nmh in near, medium, and far-term
Ken Hornstein writes: Specifically, scan can decode RFC 2047 headers, but it seems that show cannot (okay, mhshow seems to decode some headers, but not others). I'd say you've got that the wrong way round: leto:~% scan `pick -from PriorityClubeStatement` 461 2011.05.19 =?UTF-8?Q?Priority= Your May Priority Club Rew 478 2011.06.06 =?UTF-8?Q?Priority= Your June Priority Club Re 652+ 2011.12.05 =?UTF-8?Q?Priority= Your December Priority Clu leto:~% show 652 | grep ^From: From:Priority Club Rewards Email Statement PriorityClubeStat leto:~% rpm -q nmh nmh-1.3-3.fc12.i686 scan is clearly not decoding it correctly, but show seems to be doing so. Tet ___ Nmh-workers mailing list Nmh-workers@nongnu.org https://lists.nongnu.org/mailman/listinfo/nmh-workers
Re: [Nmh-workers] nmh in near, medium, and far-term
On 12/05/2011 09:03 PM, Ken Hornstein wrote: I propose just taking the current HEAD and making it nmh 1.4. Not sure if you already have, but I vote to get the maildir patch merged in before tagging 1.4. ___ Nmh-workers mailing list Nmh-workers@nongnu.org https://lists.nongnu.org/mailman/listinfo/nmh-workers
Re: [Nmh-workers] nmh in near, medium, and far-term
Ken Hornstein writes: You say that rpm says that the version is 1.3-3; is that some snapshot version? Or actually based on 1.3? It's 1.3, and it's the third build that Fedora have made from that release. It's usually rebuilt if an extra patch is added or if there's an update to a static library that it's linked against. In this instance, the only patch against a stock 1.3 is to remove some setgid permissions at install time: --- uip/Makefile.in.orig2005-12-24 12:17:38.0 -0500 +++ uip/Makefile.in 2007-01-15 20:49:42.0 -0500 @@ -283,7 +283,7 @@ # install commands with special installation needs (thus no $(SCMDS) use here) install-scmds: if test x$(SETGID_MAIL) != x; then \ - $(INSTALL_PROGRAM) -g $(MAIL_SPOOL_GRP) -m 2755 inc $(DESTDIR)$(bindir)/$$cmd; \ + $(INSTALL_PROGRAM) inc $(DESTDIR)$(bindir)/$$cmd; \ else \ $(INSTALL_PROGRAM) inc $(DESTDIR)$(bindir)/$$cmd; \ fi Tet ___ Nmh-workers mailing list Nmh-workers@nongnu.org https://lists.nongnu.org/mailman/listinfo/nmh-workers
Re: [Nmh-workers] nmh in near, medium, and far-term
Am 06.12.2011 um 03:03 schrieb Ken Hornstein: - Long term - better MIME/charset handling Specifically, scan can decode RFC 2047 headers, but it seems that show cannot (okay, mhshow seems to decode some headers, but not others). Also, the whole replying to messages that are quoted-printable or even base64 encoded ... what a mess. This one is really annoying and should be done better. In our work environment we have a exmh/nmh group email box and this gives us headaches every time. regards Andreas Verizon Deutschland GmbH - Sebrathweg 20, 44149 Dortmund, Germany - Amtsg ericht Dortmund, HRB 14952 - Geschÿftsfÿhrer: Detlef Eppig - Vorsitzender de s Aufsichtsrats: Dominique Gaillard ___ Nmh-workers mailing list Nmh-workers@nongnu.org https://lists.nongnu.org/mailman/listinfo/nmh-workers
Re: [Nmh-workers] nmh in near, medium, and far-term
On Tue, 06 Dec 2011 09:08:13 GMT, Tethys said: Ken Hornstein writes: Specifically, scan can decode RFC 2047 headers, but it seems that show cannot (okay, mhshow seems to decode some headers, but not others). I'd say you've got that the wrong way round: scan is clearly not decoding it correctly, but show seems to be doing so. One of you probably has MM_CHARSET defined and the other doesn't. 'scan' (IIRC) doesn't even try to do 2047 quoting if that variable isn't set. pgpaYcw2Imr7K.pgp Description: PGP signature ___ Nmh-workers mailing list Nmh-workers@nongnu.org https://lists.nongnu.org/mailman/listinfo/nmh-workers
Re: [Nmh-workers] nmh in near, medium, and far-term
On Tue, 06 Dec 2011 15:32:28 +0100, Andreas Wittkemper said: This one is really annoying and should be done better. In our work environment we have a exmh/nmh group email box and this gives us headaches every time. I've been getting close to getting peeved enough at exmh's behavior on replies to multiparts and QP/base64 encoding to fix it, but it's ugly to do it in Tcl if there's no nmh support. Having said that, I'm not sure exactly what the nmh side should look like to make it easiest for exmh. pgpJqyi3M5K7p.pgp Description: PGP signature ___ Nmh-workers mailing list Nmh-workers@nongnu.org https://lists.nongnu.org/mailman/listinfo/nmh-workers
Re: [Nmh-workers] nmh in near, medium, and far-term
On Mon, 05 Dec 2011 21:03:40 EST, Ken Hornstein said: I am thinking of making the nmh libraries While we have the phrase nmh libraries on the table, would it be interesting to convert sbr/libmh.a into a .so that can be embedded into other projects? I'm thinking that exmh could use that in a few places where it currently has to run system() against an nmh binary. And if uip/scansbr.c was directly callable from Tcl, that would fix a number of warts (in particular, a number of stale-data issues with the message listing frame - would also make 'rescan' and 'pack' a lot faster). pgpodPBuUdF9t.pgp Description: PGP signature ___ Nmh-workers mailing list Nmh-workers@nongnu.org https://lists.nongnu.org/mailman/listinfo/nmh-workers
Re: [Nmh-workers] nmh in near, medium, and far-term
valdis.kletni...@vt.edu writes: One of you probably has MM_CHARSET defined and the other doesn't. 'scan' (IIRC) doesn't even try to do 2047 quoting if that variable isn't set. Nope: leto:~% MM_CHARSET=1 scan +spam/unsure 652 652 2011.12.05 =?UTF-8?Q?Priority= =?UTF-8?Q?Your=20December= leto:~% unset MM_CHARSET leto:~% scan +spam/unsure 652 652 2011.12.05 =?UTF-8?Q?Priority= Your December Priority Clu Tet ___ Nmh-workers mailing list Nmh-workers@nongnu.org https://lists.nongnu.org/mailman/listinfo/nmh-workers
Re: [Nmh-workers] nmh in near, medium, and far-term
Thus spake Brian Cottingham: On 12/05/2011 09:03 PM, Ken Hornstein wrote: I propose just taking the current HEAD and making it nmh 1.4. Not sure if you already have, but I vote to get the maildir patch merged in before tagging 1.4. Me too! -- J. ___ Nmh-workers mailing list Nmh-workers@nongnu.org https://lists.nongnu.org/mailman/listinfo/nmh-workers
Re: [Nmh-workers] nmh in near, medium, and far-term
Thus spake valdis.kletni...@vt.edu: I've been getting close to getting peeved enough at exmh's behavior on replie s to multiparts and QP/base64 encoding to fix it, but it's ugly to do it in Tcl if there's no nmh support. Having said that, I'm not sure exactly what the nmh side sho uld look like to make it easiest for exmh. This reminds me of something: I have an archive of messages which nmh handles poorly. If someone wants them for testing improvements to nmh, I would be happy to provide them. -- J. ___ Nmh-workers mailing list Nmh-workers@nongnu.org https://lists.nongnu.org/mailman/listinfo/nmh-workers
Re: [Nmh-workers] nmh in near, medium, and far-term
(Replying to a bunch of messages ...) One of you probably has MM_CHARSET defined and the other doesn't. 'scan' (IIRC) doesn't even try to do 2047 quoting if that variable isn't set. It might be that I am running something newer than 1.3, and Tethys is not. Anyway, something to look into. It seems to me that we should start assuming that you should always do MIME, and always do the stuff that was previously only turned on my MM_CHARSET. I've been getting close to getting peeved enough at exmh's behavior on replies to multiparts and QP/base64 encoding to fix it, but it's ugly to do it in Tcl if there's no nmh support. Having said that, I'm not sure exactly what the nmh side should look like to make it easiest for exmh. Here's what I'm thinking. Others may chime in. First off, let us assume an UTF-8 locale (the situation gets more complicated if you do not). - When repl is reading the message to compose the reply, the message body is decoded; any base64 and/or quoted-printable data is decoded. No matter what the character set, the data is converted to UTF-8. Or maybe it's UTF-16 internally ... anyway, doesn't matter. - The data is written out as UTF-8 in the reply message. I guess if you have a non-UTF-8 locale, at this point the characters could be converted to the target character set. I think that's 85% of what you need. If you have a multipart message ... well, I am thinking of what to do there. But one step at a time, okay? :-) While we have the phrase nmh libraries on the table, would it be interesting to convert sbr/libmh.a into a .so that can be embedded into other projects? I'm thinking that exmh could use that in a few places where it currently has to run system() against an nmh binary. And if uip/scansbr.c was directly callable from Tcl, that would fix a number of warts (in particular, a number of stale-data issues with the message listing frame - would also make 'rescan' and 'pack' a lot faster). Wlll ... I'm open to that, but the only portable way I know of to do that is to use libtool. I admit to being a fan of many of the GNU Autotools, but libtool is the one that still leaves a sour taste in my mouth. Probably that has to do with it's horrible misuse in Cyrus SASL. This has come up several times though, so perhaps it's worth revisiting. Valdis, are you willing to pick up the exmh/Tcl work to use a shared library for libmh? Actually, if you could crank out another exmh release, that sure would be awesome. And if you figured out how to get exmh to use the fixed font with the most recent version of Tk, that would be super-awesome :-) (As an aside ... from my brief investigation, it seems that with the changes to the font handling in Tk you can no longer use any X font that is semicondensed, and fixing it required looking at the whole Tk font mess). Many people wrote: Not sure if you already have, but I vote to get the maildir patch merged in before tagging 1.4. Okay, the masses have spoken :-) I'll gladly do that, as soon as David Malone sends a patch (we spoke off-line and I hope I made it clear that while sending something using git-format-patch would be nice, it is completely not necessary; just get me a patch and I'll get it in there). --Ken ___ Nmh-workers mailing list Nmh-workers@nongnu.org https://lists.nongnu.org/mailman/listinfo/nmh-workers
Re: [Nmh-workers] nmh in near, medium, and far-term
On 12/6/2011 6:07 PM, Ken Hornstein wrote: ... It seems to me that we should start assuming that you should always do MIME, and always do the stuff that was previously only turned on my MM_CHARSET. +1. While we have the phrase nmh libraries on the table, would it be interesting to convert sbr/libmh.a into a .so that can be embedded into other projects? I'm thinking that exmh could use that in a few places where it currently has to run system() against an nmh binary. And if uip/scansbr.c was directly callable from Tcl, that would fix a number of warts (in particular, a number of stale-data issues with the message listing frame - would also make 'rescan' and 'pack' a lot faster). Wlll ... I'm open to that, but the only portable way I know of to do that is to use libtool. I admit to being a fan of many of the GNU Autotools, but libtool is the one that still leaves a sour taste in my mouth. ... regardless of what tool chain we use to maintain it, moving 95% of MH into a shared library is important. while i do still want to use MH from shell scripts, i think the major use of MH will be in non-shell non-text mail user agents. if MH supported Maildir format folders i could use it again. (i've switched to pure IMAP, on a Maildir folder store, after more than 20 years of straight MH userhood. painful but necessary.) but there's no way to abstract out the code that understands MH format unless we're moving all of it into a reusable code library. ___ Nmh-workers mailing list Nmh-workers@nongnu.org https://lists.nongnu.org/mailman/listinfo/nmh-workers
Re: [Nmh-workers] nmh in near, medium, and far-term
regardless of what tool chain we use to maintain it, moving 95% of MH into a shared library is important. while i do still want to use MH from shell scripts, i think the major use of MH will be in non-shell non-text mail user agents. Well, shoot, I'm convinced ... I'll look at libtoolization as part of the Automake work. But I just want to state this for the record ... as I understand the state of the art today, basically in terms of shared library support we have two options: libtool and hand-written code for each operating system. I'm not interested in working on the latter, but if someone else wants to work on it I won't stand in the way. If there are other options, then I'd like to hear about it. Also, if people have some convincing arguments against libtool, this is the point where they should speak up; otherwise I retain the right to make fun of you later :-) if MH supported Maildir format folders i could use it again. (i've switched to pure IMAP, on a Maildir folder store, after more than 20 years of straight MH userhood. painful but necessary.) but there's no way to abstract out the code that understands MH format unless we're moving all of it into a reusable code library. Hm. Okay, so I've only peripherally looked at maildir in the past. I took a quick look at it now. Some questions for you: - I assume you're using Dovecot, and as a result you want the Dovecot extensions (specifically the ones about folders). Correct? - Do you just want to be able to have scan and show work? Or do you want to do more complicated things? Just trying to get an idea of the functionality that is useful to you. And for everyone else: - For those of you who care about this, do you have any thoughts about how a mapping from an MH message number to a particular Maildir filename would work? At first glance that's the thing that leaps out at me as the most obvious problem without a simple solution. --Ken ___ Nmh-workers mailing list Nmh-workers@nongnu.org https://lists.nongnu.org/mailman/listinfo/nmh-workers
Re: [Nmh-workers] nmh in near, medium, and far-term
On 12/6/2011 7:57 PM, Ken Hornstein wrote: ... in terms of shared library support we have two options: libtool and hand-written code for each operating system. I'm not interested in working on the latter, but if someone else wants to work on it I won't stand in the way. If there are other options, then I'd like to hear about it the current (younger than me) ISC team uses and seem to love libtool, for whatever that's worth. if MH supported Maildir format folders i could use it again. (i've switched to pure IMAP, on a Maildir folder store, after more than 20 years of straight MH userhood. painful but necessary.) but there's no way to abstract out the code that understands MH format unless we're moving all of it into a reusable code library. Hm. Okay, so I've only peripherally looked at maildir in the past. I took a quick look at it now. Some questions for you: - I assume you're using Dovecot, and as a result you want the Dovecot extensions (specifically the ones about folders). Correct? i am using dovecot, yes, but i don't know what its extensions are. the dovecot people are smart and their code is BSDL not GPL so i'm inclined to say, if they like it we'll like it, and maybe we can even depend on their libraries. - Do you just want to be able to have scan and show work? Or do you want to do more complicated things? Just trying to get an idea of the functionality that is useful to you. i want it all. [ss:amd64] du -k Maildir | tail 3 Maildir/.Archives.2011/tmp 17 Maildir/.Archives.2011/cur 3 Maildir/.Archives.2011/new 48 Maildir/.Archives.2011 3 Maildir/tmp 3 Maildir/.Junk E-mail/tmp 3 Maildir/.Junk E-mail/cur 3 Maildir/.Junk E-mail/new 14 Maildir/.Junk E-mail 428869 Maildir if Mail does not exist but Maildir does, then i'd like scan, inc, show, repl, rmm, rmf, refile, pick, and so on to all work the same for me as they did when everything was in MH format. i don't think it's practical to abstract the message and folder handling out so far that MH's front end could ever be a useful IMAP interface, nor an interface to Berkeley Mail style folders. but Maildir is darn similar to what MH does now. And for everyone else: - For those of you who care about this, do you have any thoughts about how a mapping from an MH message number to a particular Maildir filename would work? At first glance that's the thing that leaps out at me as the most obvious problem without a simple solution. agreed, this is the major thing that stops UW-IMAP from being a good MH back end, too. i suspect that we'll be building a .db (or .dir/.pag) file per folder that maps the UIDL from the Maildir file name to a static number, so that things like pack and sortm can still have useful work to do. ___ Nmh-workers mailing list Nmh-workers@nongnu.org https://lists.nongnu.org/mailman/listinfo/nmh-workers
Re: [Nmh-workers] nmh in near, medium, and far-term
- For those of you who care about this, do you have any thoughts about how a mapping from an MH message number to a particular Maildir filename would work? At first glance that's the thing that leaps out at me as the most obvious problem without a simple solution. agreed, this is the major thing that stops UW-IMAP from being a good MH back end, too. i suspect that we'll be building a .db (or .dir/.pag) file per folder that maps the UIDL from the Maildir file name to a static number, so that things like pack and sortm can still have useful work to do. Alright, I'll the limits of my knowledge here. UIDL is a POP thing, right? Do you mean UID when talking about IMAP? It seems that IMAP has the concept of a message sequence number, which is a number from 1 to the number of messages in a folder; that might be the right thing to use. Of course it's not clear to me how Dovecot maps a message number into a particular filename; I'll have to look at that. --Ken ___ Nmh-workers mailing list Nmh-workers@nongnu.org https://lists.nongnu.org/mailman/listinfo/nmh-workers
Re: [Nmh-workers] nmh in near, medium, and far-term
On 12/6/2011 8:43 PM, Ken Hornstein wrote: Alright, I'll the limits of my knowledge here. UIDL is a POP thing, right? Do you mean UID when talking about IMAP? yes. It seems that IMAP has the concept of a message sequence number, which is a number from 1 to the number of messages in a folder; that might be the right thing to use. no. MH message numbers can have holes and can be reassigned. IMAP is always 1..N, no holes. Of course it's not clear to me how Dovecot maps a message number into a particular filename; I'll have to look at that. the UID is not like the IMAP sequence number. UID is a unique number that never changes for the lifetime of that message in that folder. for example a message in my Archives.2011 folder has this full pathname. Maildir/.Archives.2011/cur/1321741485.M572952P74802.ss.vix.com,S=1369,W=1407:2,FR i'm not sure exactly what all that crap is or means, 1321741485 looks like a seconds-since-1970, and M572952P74802 looks a little like device+inode. i don't know how Dovecot gets from that file name to an IMAP UID and i don't know if it does so in a Dovecot specific way or whether this is a Maildir thing (Dovecot-independent). the reason i'm thinking that we'll have a .dir/.pag file per folder is to make sure that MH message number X remains more stable than an IMAP message number would be, but less stable than an IMAP UID would be. we'd generate this db the first time we visit a folder, we'd regenerate it if the directory mtime was more recent than the db mtime, and we'd update this db whenever we ran inc, refile, pack, rmm or sortm, and we'd access this db whenever we ran show or inc or repl or similar. ___ Nmh-workers mailing list Nmh-workers@nongnu.org https://lists.nongnu.org/mailman/listinfo/nmh-workers
Re: [Nmh-workers] nmh in near, medium, and far-term
On Tue, 06 Dec 2011 13:07:41 EST, Ken Hornstein said: several times though, so perhaps it's worth revisiting. Valdis, are you willing to pick up the exmh/Tcl work to use a shared library for libmh? Sure, if it simplifies the Tcl code. Probably would end up being a exmh 2.0 requires at least nmh 1.5 or later and refuse to work with older nmh. Actually, if you could crank out another exmh release, that sure would be awesome. Let me see what I can do - the last few years I've been one of the primary committers of patches, but I've not been the one to turn the crank on the release. And if you figured out how to get exmh to use the fixed font with the most recent version of Tk, that would be super-awesome :-) (As an aside ... from my brief investigation, it seems that with the changes to the font handling in Tk you can no longer use any X font that is semicondensed, and fixing it required looking at the whole Tk font mess). I'll take a look at that, I suspect that exmh's use of fonts needs to be cleaned up since the rest of the world moved to fontconfig/cairo. pgpSWPdqhnNDl.pgp Description: PGP signature ___ Nmh-workers mailing list Nmh-workers@nongnu.org https://lists.nongnu.org/mailman/listinfo/nmh-workers
Re: [Nmh-workers] nmh in near, medium, and far-term
On Tue, 06 Dec 2011 17:45:43 EST, valdis.kletni...@vt.edu writes: And if you figured out how to get exmh to use the fixed font with the most recent version of Tk, that would be super-awesome :-) (As an aside ... from my brief investigation, it seems that with the changes to the font handling in Tk you can no longer use any X font that is semicondensed, and fixing it required looking at the whole Tk font mess). I'll take a look at that, I suspect that exmh's use of fonts needs to be cleane d up since the rest of the world moved to fontconfig/cairo. i committed a band-aid fix for this to cvs, back in april - see URL:http://article.gmane.org/gmane.mail.exmh.devel/977. the debian versions since 2.7.2-22 (ie. testing and unstable) include that fix. regards az -- + Alexander Zangerl + GnuPG Keys 0x42BD645D or 0x5B586291 + http://snafu.priv.at/ A)bort, R)etry, P)ee in drive door signature.asc Description: Digital Signature ___ Nmh-workers mailing list Nmh-workers@nongnu.org https://lists.nongnu.org/mailman/listinfo/nmh-workers
Re: [Nmh-workers] nmh in near, medium, and far-term
i committed a band-aid fix for this to cvs, back in april - see URL:http://article.gmane.org/gmane.mail.exmh.devel/977. the debian versions since 2.7.2-22 (ie. testing and unstable) include that fix. I found that fix when researching the problem. But I believe that it doesn't really get to the root of the problem. Specifically: - The Tk documentation says you can still use X font specifications to specify fonts. - However, when you do that with a semicondensed font (which is what fixed ends up resolving to) you get an entirely different font. It doesn't matter if you used fixed or the full font name; doesn't work, you get something else. That seems like a Tk bug to me. Okay, exmh is still using the Old World Order font stuff. But that should still end up with the same fonts as it did before. --Ken ___ Nmh-workers mailing list Nmh-workers@nongnu.org https://lists.nongnu.org/mailman/listinfo/nmh-workers
Re: [Nmh-workers] nmh in near, medium, and far-term
It seems that IMAP has the concept of a message sequence number, which is a number from 1 to the number of messages in a folder; that might be the right thing to use. no. MH message numbers can have holes and can be reassigned. IMAP is always 1..N, no holes. I was thinking that if we want to have something that IMAP already uses to refer to messages that is close to how message numbers work today in exmh, then that would be useful. But you say below that you want something more permament than how message numbers work today in IMAP. Alright, moving on ... Maildir/.Archives.2011/cur/1321741485.M572952P74802.ss.vix.com,S=1369,W=1407:2,FR i'm not sure exactly what all that crap is or means, 1321741485 looks like a seconds-since-1970, and M572952P74802 looks a little like device+inode. i don't know how Dovecot gets from that file name to an IMAP UID and i don't know if it does so in a Dovecot specific way or whether this is a Maildir thing (Dovecot-independent). I can fill some of this in. Most of the crap is something just guaranteed to be unique. Hence the timestamp+device+inode+hostname stuff. S=1369 is the size of the file in bytes (to avoid a stat()), W=1407 is the size of the file in CRLF format. Those are Dovecot-specific extensions. Everything after the : are file flags defined by Maildir (2 being the verison number, F means user defined flag, R means message has been read). Now, as for how Dovecot converts that to a IMAP UID ... does there happen to be a file called dovecot-uidlist somewhere? From what I see that's how the mapping from IMAP UID to filename happens. the reason i'm thinking that we'll have a .dir/.pag file per folder is to make sure that MH message number X remains more stable than an IMAP message number would be, but less stable than an IMAP UID would be. we'd generate this db the first time we visit a folder, we'd regenerate it if the directory mtime was more recent than the db mtime, and we'd update this db whenever we ran inc, refile, pack, rmm or sortm, and we'd access this db whenever we ran show or inc or repl or similar. I see that Dovecot seems to use a simple text file; maybe that's good enough for a first-level effort? Or perhaps because it's longer running it's not as much of a performance drag. --Ken ___ Nmh-workers mailing list Nmh-workers@nongnu.org https://lists.nongnu.org/mailman/listinfo/nmh-workers
