nmh-workers
[Top][All Lists]
Advanced

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

Re: [Nmh-workers] [patch] snapshot of my MIME handling improvments


From: markus schnalke
Subject: Re: [Nmh-workers] [patch] snapshot of my MIME handling improvments
Date: Tue, 30 Nov 2010 15:53:02 +0100
User-agent: nmh 1.3

I'm back.

[2010-11-13 11:31] address@hidden
> On Sat, 13 Nov 2010 00:09:21 +0100, markus schnalke said:
> 
> > - I changed Jon's attachment system to get the attachment header name
> > and format from the profile and not from command line arguments. This
> > made the involved commands and functions less bulky because the values
> > need not to be passed through all the time. It also makes this data
> > avaliable to any program who ``likes to take part''. This alone I
> > regard as an improvement.
> > 
> > The new profile names are: `attachment-header' and
> > `attachment-format'. (attach_fmt should likely be a char* too.)
> 
> Wrong way to approach it.

No. I really think that my approach is the better one.

> What if exmh (which uses nmh under the covers)

Of course, the changes will break compatibility but for a saner
solution.

> wants to add 3 attachments to a note - one an image/jpg called 'fallout.jpg',
> an Excel spreadsheet called 'estimates.xls', and a Word document called
> 'coverstory.doc'?  You *really* need to be able to specify the name, the
> mime-type, and possibly the mime-encoding of the attachment on a
> per-attachment basis.

This means every frontend for nmh needs to incorparate code to figure
out what mime type and encoding to use for any given attachment. This
truly is to be done by the backend. That's what my approach changes.

> If you don't specify mime-encoding, it must be
> intuited by looking at the mime-type (it's pointless to use anything other
> than base64 for an image/jpg, for instance), and possibly having to
> scan the attachment (a text/plain should be defaulted to no encoding
> if it's ascii, but will need quoted-printable if it contains the occasional
> non-ascii Latin chars, and may benefit from base64 if it's entirely in
> one of various non-Latin charsets).

I did mention that this part is still very poorly covered by my
proposal. But if it is once done in the backend, it's done for all.


You can't really (still) want to compose MIME parts manually, these
days? That's a task software can cover so let it do the programs.
Humans should write text (without special /^#/) and tell which files
to attach, the rest is up to the machine.


meillo



reply via email to

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