nmh-workers
[Top][All Lists]
Advanced

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

Re: [Nmh-workers] iCalendar support


From: David Levine
Subject: Re: [Nmh-workers] iCalendar support
Date: Mon, 17 Nov 2014 09:24:12 -0500

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



reply via email to

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