[Top][All Lists]

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

Re: [Nmh-workers] nmh internals: full MIME integration

From: Lyndon Nerenberg
Subject: Re: [Nmh-workers] nmh internals: full MIME integration
Date: Mon, 28 Jul 2014 20:19:46 -0700

On Jul 28, 2014, at 7:29 PM, Ken Hornstein <address@hidden> wrote:

> It's not even that ... consider the existing APIs.  If we consider iconv(3)
> to be a required dependency (something I'm seriously considering) then it's
> not so bad.  But ... I guess I don't see the gain converting everything
> internally to UTF-8; you're still converting it to the local character set
> in most cases.

The reason why I like the idea of using utf-8 internally is that it encompasses 
anything we can (reasonably) expect to see.  It makes us "lossless" internally. 
 If the display side of the environment can't handle things, well, too bad.  We 
can't reprogram people's terminals or character sets for them.  But we *can* 
make a valiant effort to downgrade the representation to something they can 
deal with, if that's at all possible.

I have to say I am a big fan of how Plan 9 handles this.  They didn't teach the 
mail software about unicode and character sets, they taught the C runtime about 
utf-8, and everything else just came along for the ride.

I know this will make everyone freak out, but let me say it anyway:  if we 
imported the Plan 9 Bio library and switched over to that, most of these issues 
would vanish.  It would make everything natively use utf-8 internally, and as 
with upas, we could transliterate between external character sets by invoking 

Switching to Bio(3) would likely be less work than a full-on 
iconv+wide-characters conversion, and upas has a 20 year track record that 
shows the scheme works.


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

reply via email to

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