[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Nmh-workers] iCalendar support
From: |
Lyndon Nerenberg |
Subject: |
Re: [Nmh-workers] iCalendar support |
Date: |
Thu, 13 Nov 2014 11:22:24 -0800 |
On Nov 12, 2014, at 11:33 PM, Robert Elz <address@hidden> 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
- Re: [Nmh-workers] iCalendar support, (continued)
- Re: [Nmh-workers] iCalendar support, David Levine, 2014/11/13
- Re: [Nmh-workers] iCalendar support, David Levine, 2014/11/13
- Re: [Nmh-workers] iCalendar support, David Levine, 2014/11/13
- Re: [Nmh-workers] iCalendar support, David Levine, 2014/11/13
- Re: [Nmh-workers] iCalendar support, David Levine, 2014/11/16
- Re: [Nmh-workers] iCalendar support, David Levine, 2014/11/17