On 2/6/2012 2:28 PM, Ken Hornstein wrote:
In the IMAP case, you don't want to download the entire message just to
satisfy an mhpath request. The value in IMAP is its ability to treat
MIME sections as separate objects. By sucking down entire messages, all
you've done is downgrade IMAP to POP.
I understand where you're coming from, but I have to ask ... when
people use mhpath to get the path of an MH message, what, exactly,
are they trying to accomplish? Usually it's something along the
lines of "use some Unix text processing tool on this message". For
that you need to download the whole thing. Obviously for something
like "scan" you don't need the whole message (well, depending on
your scan format, you might, or at least some of the beginning of
the message). I think mhpath isn't part of the "normal" flow of
MH, but if it is for people, I'm interested in how you use it (I
use it, but only occasionally, and my usage is such that I'd need
the whole message). So if you want to have mhpath return IMAP URLs,
okay, I'm fine with that. But personally I think that's not as
useful as having mhpath download the whole message.
this is an amazingly deep problem, intersecting as it does MH which
expects to have an integer represent a message, and MIME which expects
its individual parts to be addressable by the user agent, and IMAP which
expects the mail store to not be within the local file system.
i think we're going to end up extending the "message number" to be a
decimal not an integer, as in "53.6" to get MIME part 6 of message
number 53. any place that accepts a "message number" will have to
understand this, even though some places (like for example "scan" or
"pick") will signal an error if a MIME-part is specified since these
tools are explicitly whole-message. it's likely that "scan -parts"
should be willing to list the parts of each message and in that mode it
should accept the new full "part syntax". yow. this is more than just
"do it like VFS", it's a rethink just to get MIME right even before
considering IMAP.
i think ken is right above. if you run "mhpath" you're signalling your
intent to run "cat". so i could see adding a new "-nofetch" option to
force mhpath to signal an error if the folder is in an IMAP or other
off-host store... this can't be the default or it will break scripts
that work today. (i would put "-nofetch" in my .mh_profile and start
adding "-fetch" to my scripts whenever i knew it wasn't going to fill
/tmp with 3Gbytes of data... and we would release-note this to ensure
that anyone using IMAP as a folder store would be warned to add
"-nofetch" to their .mh_profile.)
...
Well, here's where I think we are regarding that:
- Paul suggested what such an API should look like (specifically, he
said "man 3 db". He said he'd do some work on designing this API
if people thought it would be a good idea.
quoting jack nicholson here: "damn. i was INCHES from a clean getaway."
- My judge of the consensus of the list was that it was a good idea;
okay, there weren't many responses. I (and maybe a few others) said
we thought it was a good idea. No one said they thought it was a
bad idea.
- That's where things stopped. I've been busy, so I didn't want to
bug Paul about it. I suspect Paul's been busy too, and didn't want
to work on it until he had a chunk of time free.
- My gut tells me that even thought there is a danger of the "design by
committee" problem, we should discuss this on nmh-workers. I think there
is enough good ideas here that it would be useful to solicit input
from people. I could be persuaded otherwise.
i think it's itinerant upon those who think this should be done, to walk
the walk. i also think that intermediate products such as example API's
and proposals should be shared with the whole list. and lastly i think
that silence will equal assent :-).
lyndon has contacted me to say he has no time just like i have no time
but that we two should make time anyway; i've agreed. i'm in
wait-and-see mode at the moment. i think i should do this but i also
have a day job and family.
paul
_______________________________________________
Nmh-workers mailing list
Nmh-workers(_at_)nongnu(_dot_)org
https://lists.nongnu.org/mailman/listinfo/nmh-workers