[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Nmh-workers] Future thoughts: better MIME processing

From: Ken Hornstein
Subject: [Nmh-workers] Future thoughts: better MIME processing
Date: Wed, 09 Apr 2014 20:59:17 -0400

Now that 1.6 is (hopefully) soon going to be out the door, I figure it's
time to think about 1.7/2.0 (I have no feelings about what the right
number should be).

Specifically, better MIME handling.  Wait, you say ... isn't that what 1.6
is about?  Yes, but I was thinking we could do even better next time.

Sometimes I have a hard time dealing with abstract ideas, so let's deal
with the specific case I've had to do a lot lately: Calendar requests,
which oddly enough I've had to respond a lot of them lately.  Yes, we
had this discussion already, here:


Mike O'Dell makes the point there that if you step back, all of this code
starts looking similar.  But let me map this to some concrete ideas based
on what I've been doing and seeing (since I've been inside of mhshow
a whole lot).

When I get a calendar request, I want to first "show" it.  Okay, that's
easy to understand.  I could write something to take a text/calendar
object and convert it to something more easily readable.  But the NEXT
thing I want to do is store it to my calendar.  On MacOS, that's pretty
easy; I save it as an .ics file, and use "open" to open it; what happens
then is Calendar opens up, asks me which calendar to store it in, and
then magically sends it to the cloud.  I could maybe add some AppleScript
glue to make that a bit smarter, but that's not really my point.  The real
issue to me is ... what is this operation?  It's not a "store", because to
me a "store" is just saving the file.  A "process"?  A different kind of
"show"?  Not sure just yet.

Replying is it's own thing.  Most text content, you want to quote back as
part of the reply.  A calendar entry you want to reply to saying you either
accept or reject the request.  So having our arbitrary MIME multiplexor
have the idea of a separate reply function/filter/whatever seems to make

I don't yet have any concrete UI or implementation ideas out there yet,
I just wanted to see what other people were thinking.


reply via email to

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