Change My Approach

It’s been a while since I last posted anything to this blog. I have been extremely busy this semester so it’s hard for me to justify spending time writing blog posts. This is particularly true given that I’m blogging mostly as an experiment anyway.

I think if I’m going to survive as a blogger I need to change my approach. Instead of trying to post relatively coherent and hopefully well thought out articles, I will just say a few words now and then about whatever crosses my mind. That will make writing posts easier and thus more likely that I’ll actually do it. It will also make this blog truly just “technically rambling,” and will probably more in keeping with the original spirit of web logging.

We’ll see how that goes.

HTML Email is Not Evil

I’ve reviewed the various objections to the use of HTML in email and, honestly, I think they are all fallacies. In many cases the objections seem to be more about the way HTML email is implemented in current mail clients than about HTML email itself.

The document here summarizes a number of common objections to HTML email. In this post I will offer a rebuttal to these objections. However, I should first point out that I might be attacking a straw man. Most of the anti-HTML email pages I’ve seen are relatively old. The issue appears to be generally less controversial now than in the past.

Here are the objections from the document referenced above, along with my comments.

1. HTML email is dangerous.

Here the objection is especially with regard to scripts but also with regard to other kinds of browser vulnerabilities (since HTML email is often rendered with the help of a browser plug-in of some kind). However HTML itself does not specify scripting other than to say that there exists a script element. A perfectly compliant HTML rendering engine could ignore all scripts. To me this seems like an obvious way to handle the issue. Plain HTML is passive and not especially dangerous.

2. HTML e-mail wastes bandwidth.

Certainly it is true that an HTML message will be larger, perhaps two or three times larger, than a plain text message. However most normal email messages are not very large. If I take a 2 Kbyte plain text message and bulk it up by a factor of five it is still only 10 Kbytes. In comparison consider the size of all the annoying ads and icons one typically downloads on the web pages one visits. Consider the amount of spam that circulates around the network. I suspect the bandwidth consumed by such junk is many times greater than anything likely to be consumed by legitimate HTML email. If one is concerned about clogging the network with crap, going after legitimate HTML email is not the answer.

3. HTML e-mail doesn’t always work.

Here the objection is that not all mail clients support HTML email. However, the lack of such support is becoming increasingly rare. Every modern client I’ve seen recently handles it. Even the text mode client pine displays HTML email in a reasonable way. In any case the multipart/alternative MIME type allows both plain text content and HTML content to be sent in the same message. This standard exists precisely to support mail clients that don’t understand HTML email while still allowing HTML email to be used with clients that do.

4. HTML e-mail can connect to the internet by itself.

Here the objection is to HTML messages with embedded images (for example) that use absolute URLs to access the image data. Again, this does not seem to be a problem for modern clients. For example, both Pegasus Mail and Thunderbird refuse to fetch images in such messages without explicit permission from the user. Again this objection is really about mail client implementations and has little to do with HTML email itself.

5. HTML e-mail renders slowly.

Here the objection seems to be about the added complexity HTML email imposes on mail clients. Certainly it is true that rendering any kind of rich text message is going to require more effort on the client side. So what? If one accepts that rich formats are useful (more on this below), then isn’t that complexity part of the application I want to execute?

6. HTML usually looks [horrible].

There is no doubt that some HTML email is really hideous. However, this is not a problem with HTML email itself. Instead it is a problem with the way people use it (or perhaps with what mail clients allow people to do with it). The solution is not to pull HTML email out of the hands of those who use it responsibly but rather to educate the people who don’t.

7. Digested lists hate HTML mail.

This sounds like a problem with the list digesting software to me. Why should a digest change the MIME type of the included messages? Perhaps the author of the digesting software thinks they are doing people a favor by converting the MIME types of all messages to text/plain. If so, that has little to do with HTML email. It is entirely related to an arbitrary design decision by the digesting software author.

Some people say that sending HTML email is pointless because the mark up adds nothing of significance to the content anyway. However, if that were really true then why do people use word processors when writing documents? Why aren’t all our documents in plain text? HTML adds a number of useful structural features like lists, tables, and embedded images to name three. Why not use them?

In fact, I’d like to go beyond what current mail clients seem capable of doing. I want to send potentially complex mathematical formula, together with associated line drawings through the mail. I don’t want HTML email, I want XHTML email that uses multiple XML name spaces! If the anti-HTML email crowd has its way, email messages will be forever stuck in the dark ages of document formatting technology.

Fortunately, as I mentioned earlier, the HTML email debate seems to be fading. HTML email is here to stay. Now we need to push for the next level.

Concurrent and Real-Time Programming in Ada

BOOK REVIEW

Concurrent and Real-Time Programming in Ada by Alan Burns and Andy Wellings. Copyright 2007. Published by Cambridge University Press. ISBN=978-0-521-86697-2.

This book gives the reader a good foundation on how to do concurrent and real-time programming in Ada, while also exploring the new features in Ada 2005. The authors don’t bother to provide an introduction to the language; familiarity with the basic constructs of Ada is a necessary prerequisite. However, on the topic of concurrent programming in Ada the text is exhaustive and authoritative.

Although the book obviously has a strong Ada focus, the authors start with a nice discussion of concurrent programming in general terms. They describe various alternatives for handling concurrency in an balanced, objective way, pointing out that Ada’s approach (which is to offer strong support for concurrency in the language itself) is not the only way to build concurrent systems.

The book is divided into two main sections. In the first part, Ada’s tasking model is described. First presented are the details of how tasks are created, including specifics on task hierarchies and the order in which nested tasks are activated, etc. The authors then give the details of how Ada’s select statement works, including features such as timeouts, termination alternatives, and asynchronous selects. The details of protected objects (basically monitor-like constructs that supports mutually exclusive access to shared data) are also provided. Many examples are given to support the discussion.

The first part ends with a chapter presenting a skeleton library of tasking primitives that use Ada’s object oriented features to good effect. For example, Ada allows you to implement an interface using a task or a protected object rather than an ordinary type. This allows you to treat task related abstractions polymorphically in your program. This seems like a very powerful feature (new with Ada 2005) and I enjoyed seeing it in action.

The second part of the book focuses on Ada’s support for real-time programming. This includes the handling of task priorities and scheduling policies. The authors discuss how to avoid priority inversion by setting “ceiling priorities” on protected objects. Details of Ada’s scheduling algorithm are given, and examples are shown that illustrate how to write programs using advanced scheduling features: dealing with multiple scheduling policies at the same time, handling missed deadlines and execution time overruns, building “execution servers” that support various policies, etc. The authors also describe how Ada handles hardware interrupts and software generated “events,” and how programs can execute periodic tasks effectively.

Ada 2005’s support for real-time programming is extensive, but many of the features it provides are features more typically found in operating systems. This is perfectly reasonable in cases where the Ada run time system is also the operating system—such as when Ada is used for embedded development on the bare metal—but it’s not clear how well these features would work (or if they would even be implementable) on top of some conventional operating system. However, many of the real-time features described in this book are part of the Real-Time Systems annex, an optional part of the Ada standard that would no doubt be ignored in environments where it doesn’t make sense.

The second part of the book ends with a skeleton library of real-time abstractions, following the approach given in the first part of the book. The authors offer both of these libraries as starting points for discussion in the Ada community and clearly hope that they can be evolved into something that might become part of a future Ada standard.

The final chapter of the book is on the Ravenscar profile… a subset of Ada’s tasking features that are easier to implement (and thus can be implemented more efficiently) and easier to analyze (and thus suitable for high integrity programming were correctness is more important than convenience). Although the Ravenscar profile removes quite a few powerful features from Ada’s tasking support, the resulting language is still useful as the authors demonstrate with several examples. I was interested in the fact that Ada provides a standard way for disabling language features. Thus features that are problematic to understand or analyze can be turned off according to local policy to produce a simpler language that is more appropriate for specialized needs. I believe Ada may be unique among programming languages in providing this sort of support in its standard.

In summary “Concurrent and Real-Time Programming in Ada” is a ‘must read’ if you are interested in mastering Ada. Even if your interests are just in the area of concurrent programming, this book would be good to study. Learning how Ada handles this important topic is enlightening no matter what language or approach to concurrency you use.

Blogs Are Pointless

I’ve been watching the increasing popularity of blogs with some interest. Yet I can’t figure out the point of them. Do people really think everyone in the world is interested in their thoughts? Blogs often contain collections of random posts that are related only by way of the blog author who posts them. Is that really the sort of thing to which others (besides perhaps family and friends) would subscribe? Also blog postings clutter search results with hits that may or may not be accurate or useful. Is that really a service to the Internet community?

I can see the value in a tightly focused blog that is written by a major player in whatever field the blog is covering. Don Syme’s blog on F# is a good example of that. So perhaps instead of saying all blogs are pointless what I really mean is: this blog is pointless.

I thought about trying to keep this blog tightly focused on one of my areas of interest, but I decided for now to not restrict myself. After I gain some experience with blogging I will probably have a better idea of what I want to do and what the point of it might be. Until then I will just ramble about various technical topics as they come up for me. If nobody reads this, that is fine. Meanwhile I’ll have fun playing with WordPress.