Oliver wrote:
David Levine wrote:
2) For each switch, repl puts one pseudoheader in the draft of form:
Nmh-mhbuild-TYPE: [ARGSTRING] file://FILE
What is the URL style file:// syntax needed for? Is it sometimes http or
something?
No, while it looks familiar, it's only used here as a delimiter
for the filename. It's very unlikely to be part of a filename.
Any other suggestions? Or, we could split into two
pseudoheaders, one for the ARGSTRING and one for the FILE.
Example 1, text/calendar:
1) repl switch -converterarg text/calendar '-reply accept'
2) pseudoheader: Nmh-mhbuild-text/calendar: -reply accept file://FI
LE
3) mhn.defaults entry: mhbuild-converter-text/calendar: | mhical
4) mhbuild filters thru: mhical -reply accept
Is mhical generating a mime part to indiate acceptance of the
invitation to the originator once they receive your reply?
Yes, with "-reply accept". There's also "-reply decline",
"-reply tentative", and "-cancel".
Is adding the appointment to your own calendar something you
handle as part of mhshow?
No, that's outside the scope of nmh. The user could write a
mhshow-show-text/calendar profile entry to update their
calendar, of course, if it's possible to do that from the
command line.
Is such a long pseudoheader necessary, didn't we switch to just 'Attach'
for attachments.
There's no need for brevity here, these aren't supposed to end
up in the outgoing message. But, if one does leak out, or if an
nmh user sees it, they'll have a pretty good clue to where it
came from. Worst case, they'd be a quick web search away. I
don't like undecipherable relics and strongly feel that nmh
doesn't need to contribute more.
Speaking of "Attach", it used to be "Nmh-Attachment". The
change snuck by me. I'd like to change it back (to
"Nmh-Attach") for the reasons noted.
How about substituting the command instead of including the
mime-type in the header name:
GenAttach: mhical -reply accept FILE
Then repl would have to know how to convert any type. The type
is necessary to select the command, which is configured in
mhn.defaults or the profile. (The type really doesn't have
to be a MIME type, any string that's legal for a MIME type will
work.)
And what is the mime type of the converted file? Would it use
file like for normal attachments?
No! :-)
text/calendar is what it matched in the message being replied
to; I don't know what calendar acceptances use
text/calendar, also
but for the feature to be flexible, the type of the converted
text might need to be different.
Good point. This could fit into the scheme for adding
Content-Type parameters such as "method" that I mentioned. The
converter would pass back the C-T header, which could contain a
different type than in the message being replied to.
For html or text parts, it'd be more useful to have the processing as
part of repl/forw itself when it prepares the initial draft and not in
mhbuild. If I want parts attached with mhbuild, I'd have no need to
convert them.
What if they're base64 encoded?
repl needs to add the '> ' quotes
I'll have to look again, it might be possible to do the conversions
before repl does its formatting. Though there is benefit in having
par insert the prefix, not everyone uses that.
and it could do the iconv stuff internally.
repl doesn't do that now and this general approach incorporates it.
David
_______________________________________________
Nmh-workers mailing list
Nmh-workers(_at_)nongnu(_dot_)org
https://lists.nongnu.org/mailman/listinfo/nmh-workers