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 [email protected] https://lists.nongnu.org/mailman/listinfo/nmh-workers
