[Top][All Lists]

[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 

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 

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 

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.


Attachment: signature.asc
Description: Message signed with OpenPGP using GPGMail

reply via email to

[Prev in Thread] Current Thread [Next in Thread]