On Nov 12, 2014, at 11:33 PM, Robert Elz <kre(_at_)munnari(_dot_)OZ(_dot_)AU> wrote:
Treating ical as a special case will just lead to demands for similar treatment of the next magic mime type that becomes popular. Please don't go there.
I agree completely.
For dealing with repl, which is what is the biggest concern to most of us, I think, the real question seems to be what that means.
I think this nails the problem on the head. What is repl? It seems that many people think it is the single vector for generating any and all replies. I disagree. I see repl as a tool for managing one part of a human-to-human correspondence chain. It's designed for interactive editing and entry of text in the context of an ongoing conversation. But it is far from the only mechanism for generating a response to a message, and to treat it as such is an anathema to the MH design philosophy. Robert provided an example of scripted automation for generating replies to messages, Let me contribute one of my own. When I was actively managing mailing lists I had to deal with quite a bit of mail that was blocked by the list management software for policy reasons. Those messages were forwarded to me for disposition, that being handled by re-forwarding the message to the list with a magic header included, or replying to the original sender with a rejection reason. It was trivial to implement this in two shell scripts, one to accept, and one to reject. In both cases, the scripts used mhshow to extract the encapsulated message into a temp file for processing, which was done by the script, with the result being submitted directly to sendmail for onward delivery. This model used the parts of MH that were helpful, and used other tools that were suited to the rest of the job. This is what MH excels at – supporting the UNIX tools based approach to problem solving. Dealing with calendar parts can and should be dealt with in the same manner. My approach would be to implement a very simple formatter that would print the calendar attachment in a human-readable way. Beyond that, I would write a pair of scripts – one each to accept and reject an invitation. Those scripts would work just like my accept and reject scripts for the mailing list manager. Use MH to extract the calendar MIME part, then use awk and friends to extract from it the bits required to generate an appropriate reply, and finally call sendmail to send the response. The display formatter could be included as part of the MH base code. But the inviteaccept and invitedeny (for a lack of any better name) scripts would be contrib fodder at best. The reason being that calendar processing almost always includes interaction with external calendaring software. In my case, I would want to push accepted invites into Calendar on my Mac. Others might want to send them to a CalDAV server. Or stuff them into a private sqlite database. Maybe I first want to query one of those external calendars to look for conflicts. That would require a third command so specific to my setup that nothing we could provide would do the job. And nor should we. MH is not a calendar manager any more than cc is an MP3 player. We have to stop thinking about specifics and take a step back. I think what's missing is the recognition that we need two distinct APIs – one geared toward interactive (human) use, and a second tailored specifically for external programatic processing of content. We already have a need for this internally, as shown by the multipart/signed discussion. But the ways people are talking about torturing the repl interface clearly points out the need for a better non-interactive command line interface as well. Our concentration needs to be on designing on that generic interface, not on anticipating how to directly manipulate every possible type of embedded content. --lyndon
signature.asc
Description: Message signed with OpenPGP using GPGMail
_______________________________________________ Nmh-workers mailing list Nmh-workers(_at_)nongnu(_dot_)org https://lists.nongnu.org/mailman/listinfo/nmh-workers