The whole point of my emails is that I *do* intend to work on this, but
I'd like to get it right. While I'm on that point, though, could you tell
me where I should put this work? Bug reports with submitted patches and
patches on Savannah don't seem to be picked up.
That's great. Thanks for contributing. Since I'm not sure that this is a
bug as opposed to a new set of features, I'd just check 'em in. If bug repor
ts
don't seem to be working, please contact the Savannah admin. I've done that
in the past when things were clogged up on their end. As far as I can tell,
everything is set up correctly.
The bug reports (with patches) that I've done over the past couple of
months are certainly there, but nobody's picking them up. I'm pretty sure
it's not a Savannah problem. There are reports (with patches) from other
people that go back a year or two.
I wasn't assuming I'd be given CVS access, which is why I've been using
that mechanism.
I would change it to get rid of
the whole mime-composition file thing. I would change forw and repl so t
hat
they build attachment headers instead of mime composition files. Aha! N
ow
that I'm rambling on here, I'd add a -attach option to other programs, or
a single attach option as Oliver suggested earlier. If the attach option
is not set, things should work as they do today. If it is set, then forw
and repl should use attachment headers.
I'm happy to add that. How about something like if the attach command
in whatnow is given a number, it interprets it as a message number and
forwards a message rather than attaches a file? To save having two
different types of header, mhbuild/send could do the same thing. Attaching
a file that is a number would still be easy though, since you could
do something like ./123
This doesn't sound good to me. I don't want to break the existing attach
command format. Also, attaching files is the main thing here to me, not
forwarding messages. My suggestion is to modify the forw and repl commands
so that if a -attach option exists they add an attachment header with the
name of the message being forwarded or replied to. If that's not clear
enough, what I'm suggesting is that
forw 123
when the folder is my inbox make a message that begins with
X-MH-Attachment: /home/Mail/jon/inbox/123
Of course, the X-MH-Attachment field name is whatever you specify.
I probably didn't make clear why I thought the magic I described would
be needed. Messages should be encpasulated in message/rfc822 parts, and
I don't like the idea of mhbuild or anything else trying to figure out that
a text file is in fact a message. So unless a second kind of header is
introduced, it needs to be done based on filename. How would you do
this?
I'm a bit confused by the discussion of encapsulating a mime message in a
mime message. It's no big deal. What you want is to take the message th
at
you're encapsulating and make it a single part of the new message; you do
n't
want to split it into parts and then put each part into the new message.
I also thought you'd say this. Perhaps I'm missing something, but I don't
see how you could reliably parse the headers of the message being
encapsulated, and you need to, because some of that must become headers
of the new message, such as To: and cc:. Some of it, however, can't be,
such as content-type, which might have to be changed to multipart as
a result of the attachments being done. The message body, of course,
is easy.
Not sure that I need to responed because you probably know what I'd say :)
I wasn't talking about encapsulating the whole message, just the message
body. That's the behavior that I'd expect. It's easy to split the body
from the headers, and it's easy to encapsulate the body. But in any case,
I wouldn't bother. I'd suggest that doing the above mentioned change to
forw and repl would make it unnecessary.
Now I really think I'm missing something. :) I don't see that it's easy
to split the body from the headers if the message is already MIMEd, because
it might be a multipart message, or it might not, and so unless you want
to encapsulate all the headers too, and just copy the ones you know you
need to the new message, the headers of the old message need to be
parsed to know how to correctly encapsulate it.
Perhaps you're saying that the parsing of the original message's headers
is easy? That the MIME headers just need to be lifted out, leaving the
headers from which to create the new message, and then those extracted
MIME headers are used to encapsulate the original message?
Cheers,
- Joel
_______________________________________________
Nmh-workers mailing list
Nmh-workers@nongnu.org
http://lists.nongnu.org/mailman/listinfo/nmh-workers