Re: [boost] Re: HTML-format mails

From: David Abrahams (david.abrahams_at_[hidden])
Date: 2002-06-07 11:22:35

I hate to be a buzz-kill, people, but this is getting a little too serious
to be considered on-topic for boost...

Thanks,
Dave

----- Original Message -----
From: "Terje Slettebø" <tslettebo_at_[hidden]>
To: <boost_at_[hidden]>
Sent: Friday, June 07, 2002 12:05 PM
Subject: Re: [boost] Re: HTML-format mails

> >From: "Mattias Flodin" <flodin_at_[hidden]>
>
> >A more appropriate metaphor would be C++ compilers for embedded systems.
> >Full support for the minimum standard, but running in a rather
> >restricted environment. And, afaik, we do want to support that. :)
>
> Just to give my 0.02 on this, as well.
>
> I can understand the resistance to HTML mail on a mailing list. We have
the
> same policy on the ACCU mailing lists - no HTML mail. In fact, any HTML
part
> is automatically stripped by the mailing-list software. Which makes the
mail
> look rather funny if it _only_ contains an HTML component, as it then
> results in an empty mail. :)
>
> James Curran said in the original posting:
>
> >    With compilers, we write to the most modern standard, begrudgingly
> >support old compilers, and consider those to insist on using such old
> >compilers as holding back progress.
>
> I can understand this notion very well, because I reacted with similar
> disbelief, when someone I know, a programmer, refused to use HTML mail,
on
> the grounds that it took more space to send. If you only send the HTML
part,
> it more or less takes the same space, though. If you were to use some
kind
> of non-HTML markup, you'd need to mark it some way, anyway, like
> _underline_. Also, if it was sent compressed, it should be about as small
as
> text mail.
>
> So I found this argument rather reactionary, when you consider the
benefits
> of being able to format the text. It would be like the change from plain
> text, to word processors, to finally also happen for email. I find it
even
> stranger given that it's common to send movies or music across Internet.
The
> bandwith taken by email, text (HTML or not), for people, would typically
> only be a tiny amount of the bandwidth used for web access.
>
> However, for mailing lists, this may be different.
>
> Coming back to the compiler argument. Yes, it's nice to be able to write
> standard C++, and the Boost libraries (and libraries like Loki), really
push
> the compilers, and therefore the vendors, to make more compliant
compilers.
> However, because Boost also aims to be portable, also for not so
compliant
> compilers, the libraries are typically made more portable, across
compilers.
>
> The same argument may be used for mailing lists. There may be a wide
variety
> of mail clients, however they all at least support plain text, as a
common
> denominator. Also, even if the clients do support HTML, some may not want
to
> use it.
>
> Therefore, I've tended to only use HTML mail, if I've known the other
one's
> mail client was able to handle it (which you can often tell from the mail
> header). It can be quite useful for sending code, because you can use
> fixed-space font for that part, and you avoid the wrapping. That also
goes
> for the rest of the mail - the wrapping is adjusted to the size of the
text
> window, rather than some arbitrary limit.
>
> However, for mailing lists, like the Boost libraries, it may be better to
> use a common denominator handled by all mail clients, or preferences.
>
> >It has just elected not
> >to support HTML format mails (which, afaik, are not part of the SMTP/POP
> >standard).
>
> I think HTML mail is reasonably well standardized, since it uses MIME,
> which, as I understand, is part of the SMTP/POP standard, now.
>
>
> Regards,
>
> Terje
>
>
> _______________________________________________
> Unsubscribe & other changes:
http://lists.boost.org/mailman/listinfo.cgi/boost
>