Buildout with Repoze, Zope, and Plone

I know in my last post I indicated that I'd post more about the various technologies I'm using for the Antichrist Watch site, but I've now had a few requests related to some of the Repoze work I'm doing with some of the local Saugus, MA sites, so I'll be making a slight detour. I will get back to the Dojo stuff. I promise.

I discovered Repoze when first dabbling around with what would eventually become the aforementioned Antichrist Watch, and in fact I directly made use of repoze.chameleon to handle its templating needs. I liked what I saw, and decided to try first experimenting a bit with it and then actually porting over some real-world sites to it. We were in the process of doing some hardware upgrades on the some servers anyway, so the sites they hosted seemed liked good candidates. To make things interesting, most of them came in basically two distinct flavors: straight Zope, and customized Plone.

The first group was largely composed of mostly non-technical customers who take advantage of the bottom of the so-called "Z shaped curve" to do basic site edits through the Web. Some of these customers enjoy having fairly current versions of Zope. The second group featured various degrees of customization, from the fairly vanilla to the strikingly different. Most of these were handled via custom Plone products designed more or less in the manner described in Martin Aspeli's Professional Plone Development. With this logical grouping, buildout seemed a logical choice for site construction as I could make just three buildouts and then trivially generate as many sites as desired. The only problems were that the Repoze guys themselves seem not to use it much and (understandably considering the drudgery involved) don't have prepackaged versions of the latest-and-greatest of either Zope or Plone currently available.

Ultimately I wanted all the sites running through mod_wsgi using as few physical servers as practical. I wanted to only have one supervisord instance per physical server monitoring all the ZEO servers it contained. I also wanted to minimize the number of ports in use in order to reduce the bureaucracy of port tracking we'd have to do afterwards.

Getting current versions of Zope and Plone running under Repoze turned out not to be so simple. I read a few articles on the topic in addition to the Repoze Quick Start, but due to differences in versions and/or environment none of them did what I needed.

Making It Happen

Enough introduction! Here's what I did for the variant with Plone:

1. paster create -t zope2_buildout targetname

   It doesn't much matter what answers are given, as buildout.cfg gets overwritten anyway.

2. cd targetname

3. Replaced buildout.cfg with the following:

   [buildout]
   extends =
       http://good-py.appspot.com/release/repoze.zope2/1.0
       http://dist.plone.org/release/3.3rc3/versions.cfg
   
   versions = versions
   
   find-links =
       http://dist.repoze.org/zope2/latest
       http://dist.repoze.org/zope2/dev
       http://dist.plone.org/release/3.3rc3
       http://download.zope.org/ppix/
       http://download.zope.org/distribution/
       http://effbot.org/downloads
   
   develop =
       src/mysite.policy
   
   parts =
       zope2
       instance
       slugs
       addpaths
   
   [zope2]
   recipe = zc.recipe.egg
   dependent-scripts = true
   interpreter = zopepy
   eggs =
       repoze.zope2
       Plone
       PIL
       Products.DocFinderTab
       Products.ExternalEditor
       plone.openid
       mysite.policy
   
   [slugs]
   recipe = collective.recipe.zcml
   zope2-location=${buildout:directory}
   zcml =
       mysite.policy
   
   [instance]
   recipe = iw.recipe.cmd
   on_install = true
   cmds =
      bin/mkzope2instance --use-zeo --zeo-port=${buildout:directory}/var/zeo.zdsock --zope-port=8888
      sed -i "" "s/server localhost:/server /" ${buildout:directory}/etc/zope.conf
      echo "Please run 'bin/runzeo -C etc/zeo.conf' and 'bin/paster serve etc/zope2.ini', then 'bin/addzope2user  '"
   
   [addpaths]
   recipe = z3c.recipe.runscript
   install-script = addpaths.py:main
   update-script = addpaths.py:main
   

4. Added the file addpaths.py to the buildout's top level directory with the following contents:

   import os
   from dircache import listdir
   
   BinDir = 'bin'
   UnadornedFiles = ('bin/zope2.wsgi',)
   RegularFiles = ['%s/%s'%(BinDir,filename) for filename in listdir(BinDir)]
   EggDirs = ('eggs',)
   ProductsPath = os.path.abspath('products')
   
   def main(options, buildout):
       for filename in UnadornedFiles:
           lines = open(filename,'r').readlines()
           file = open(filename,'w')
           alreadyProcessed=False
           for line in lines:
               if line.startswith('import sys'):
                   alreadyProcessed=True
               elif line.startswith('import os') and not alreadyProcessed:
                   file.write("import sys\nsys.path[0:0] = [\n")
                   for eggDir in EggDirs:
                       for filename in listdir(eggDir):
                           file.write("  '%s',\n"%os.path.abspath('%s/%s'%(eggDir,filename)))
                   file.write("  ]\n\n")
               file.write(line)
       for filename in RegularFiles:
           lines = open(filename, 'r').readlines()
           file = open(filename, 'w')
           for line in lines:
               file.write(line)
               if line.startswith('sys.path'):
                   file.write("  '%s',\n"%ProductsPath)
           file.close()
   
       print "Egg paths added to %s" % ', '.join(UnadornedFiles)
       print "Product path added to %s" % ', '.join(RegularFiles)
   

5. python2.4 bootstrap.py

6. bin/buildout

   Just ignore any 'return' outside function types of errors you see.

Once these steps have been completed, ZEO can be started with the command bin/runzeo -C etc/zeo.conf (which can be easily controlled via supervisord) and Zope can be started manually for testing with bin/paster serve etc/zope2.ini or in a more production-ready form via mod_wsgi using zope2.wsgi.

Details To Note

I borrowed but heavily modified the addpath.py concept already living in the Plone collective to add all missing paths to all the scripts in bin. The WSGI script as created lacks pretty much everything, and all the others lack the products directory used for old-style products. As written it's not very clever and could be greatly improved, but it serves my current needs.

The order of parts matters somewhat, as both slugs and addpaths rely on pieces created earlier.

I'm using direct sockets in lieu of ports since these sites are living on single physical servers anyway and it means I have less to manage afterwards. Unfortunately the mkzope2instance doesn't do exactly what one might want in this case, so the sed line is necessary afterwards to clean up.

The slugs section adds ZCML slugs for those products that need them, including the hypothetical product mysite.policy being actively developed in src.

I just recently discovered Martin Aspeli's Good-Py. I was originally individually pinning the versions of the pieces that mattered, and only made this simplification this morning... so far it seems to be fine, though.

Just before starting this post I spotted Alex Clark's post also discussing this topic. We're doing a lot alike, but a few things differently. Depending upon what you're doing, you may find that what he's doing more directly addresses your needs.

Earlier on I mentioned how I needed to handle two main groups of sites: Plone ones and straight Zope ones. The above instructions only cover how I handled the Plone ones. This post has gotten long enough already, and although my treatment of the straight Zope ones is similar it's different enough to make things confusing for those who don't need it. If you need it, let me know and I'll probably give it a similar treatment to what I did here.

Antichrist Structure

Last time I mentioned how I'll post some articles discussing how some of the key technologies (like the Dojo Toolkit, PostgreSQL, Twisted, Zope, Python, and Repoze) are used by Antichrist Watch. In this post I'll discuss some of the general architecture behind the site, along with motivations behind some of the design decisions I made. In future posts I'll follow up with specifics related to some of the key technologies employed.

I've already covered the originally planned core features of the site, so I won't repeat them here. What's important for this discussion is that those features require fast access to live data on votes, tallies, and comments, and the ability to display that data in a number of ways, and that everything be done cleanly according to current industry standards (that is, using decent semantic HTML backed by appropriate CSS and RDF that'll not cause the respective W3C validators to choke). Obviously an AJaX design is called for, and the individual toolkits and frameworks used must be flexible enough to support reasonably standards-compliant code and mark-up. This may sound trivial on the surface, but oftentimes toolkits, frameworks, and even design tools have their own axes to grind and introduce deliberate incompatibilities or proprietary extensions in an attempt to promote their own stuff or denigrate others' stuff.

PostgreSQL for the back-end database was an easy choice. It performs well, has great support for standard SQL (and even XML) built-in, and has advanced capabilities like triggers, rules, and stored procedures that can be used to help ensure data integrity. I'm a big believer in keeping code that enforces data integrity as deep within a Web application as practically possible; the closer it is to the front-end the more space there is for something to go wrong. With PostgreSQL I was able to get most of the code that handles data integrity embedded in the database itself, so not only is there not even a theoretical way for a crafty user to bypass constraints, there's not even a theoretical way for misbehaving middleware to bypass them. I'll discuss this in more detail later.

The Dojo Toolkit for the front-end JavaScript will be surprising to some as many believe its recent (post 1.0) versions cannot be used within a site that validates. This is incorrect. What is true is that Dojo's Dijit widgets can not be used in a validating site via mark-up without modifying Dojo's parser. This is a completely different statement, as there are other (and better) ways to apply Dijit widgets to a site. I'll discuss my use of the Dojo Toolkit in quite a bit more detail later. Most of the site's code is actually Dojo code, so I suspect I'll dedicate a couple of posts to it.

Of course, the JavaScript needs to be tied into some mark-up, and for this I used a single Zope Page Template designed to output clean XHTML. This would be trivial for a typical Zope site, but in this case it's certainly not typical as only scattered Zope technologies are being used. I'll get back to this in a bit.

The Dojo Toolkit has the concept of an abstracted data store that it leverages heavily for most of its widgets. It has numerous concrete implementations of this store that make binding it to various data sources fairly trivial. The one it includes for dealing with relational databases requires data to adhere to a particular format that would be awkward to generate directly in PostgreSQL, so it was necessary to create some code to fetch data from PostgreSQL and format it for Dojo. Since I had already built a great deal of intelligence into the PostgreSQL database itself, it was actually fairly simple to create this middleware, and during development I tested out a couple of different approaches (including raw Python and PHP) before settling on one designed around Twisted Python. It makes good use of Twisted Enterprise and the psycopg2 database adapter (including its splendid DictCursor) to make database access fast, efficient, and comprehensible. I also tied the rendering of the main Zope Page Template into this Twisted app by virtue of Repoze Chameleon in lieu of making it a typical Zope site. This whole layer is probably also worthy of its own post.

That's a quick run-through of what it takes to reveal the Antichrist. I'll be posting more details on these individual components later; please feel free to point out areas of particular interest.

Who Is The Antichrist?

I know it's been a long time since I've written anything here. A really long time. I figured I'd break this silence with an overview of a project I've been working on lately that will hopefully prove interesting.

It's a site called Antichrist Watch. It's a site that attempts to answer this article's titular question who is the Antichrist? in a Web 2.0 sort of way using a fun mix of AJaX technologies.

I recently realized that much of the work that I do ends up buried within various intranets and extranets and is thus invisible to the world at large. While I've worked on all sorts of dynamic systems that do all sorts of things (both server-side and client-side), I really don't have any that I can show people. Most of the public sites that I work on tend to be simpler sorts of things, and people viewing them tend to mostly remember the graphics design elements (which in most cases I didn't actually work on anyway). With Antichrist Watch I have something that I can show both curious acquaintances and potential clients. The dynamic properties of it are fundamental to how the site works, and even people not all that familiar with the Web can get it.

Under the hood it uses a somewhat unusual combination of key technologies that not too many others use together: the Dojo Toolkit, Zope, Twisted, Python, and PostgreSQL. While people familiar with my company Saugus.net will not at all be surprised with Zope, Python, and PostgreSQL (we've been using them all pretty prominently for years), Dojo and Twisted may be unexpected. We've actually also been using these off and on for quite awhile too, but not in too many public projects. In fact, thinking back, there are currently only two public areas of Saugus.net sites that utilize Dojo, and no public areas at all that use Twisted. While we are hoping to change this in the relative near future, Antichrist Watch demonstrates how these technologies can work together in harmony now.

While I'm still working on the site fixing bugs and adding new minor features, all of my originally planned core features are in place:

1. The ability to vote on one's own choice of Antichrist, whether or not he or she is already in the list, with autocompletion based upon the live list of everyone's past choices.
2. Charts and tables showing current leaders for the past day, the past week, the past month, the past year, and all time.
3. Additional charts and tables showing votes as they come in with individual votes mapped to rough geographical areas, and the recent levels of voting activity over time.
4. A way to drill down and see the numbers for any particular Antichrist candidate.
5. A facility that allows one to argue for or against the likelihood of a particular Antichrist candidate being the Antichrist, respond to others' comments, and display it all in a tree.
6. The means to moderate the aforementioned comments.
7. A login system allowing people to establish identities within the site and voluntarily add personal information that will be displayed along with their comments to add personality.
8. Support for various icon types to go along with login identities, including at minimum PIcons, Gravatars, and .Mac icons.
9. Support for OpenID to ease the whole login process.
10. Basic support for forward and back buttons within the site.
11. A reasonably semantic design including a fully populated external RDF metadata file boasting appropriate Dublin Core terms and DOAP information (plus a few other useful nuggets).
12. Cleanly handle the full UTF-8 character set throughout.
13. Proper validation of pretty much everything according to the W3C's respective validators.

It does all of this in a way that almost totally avoids page reloads (the only exception is with OpenID authentication which by definition requires a redirect offsite and back). It also heavily makes use of lazy loading within its tables and trees, so that although access is provided to all data all the way back to day one, only data actually required for the current view gets downloaded keeping things fast on both client and server side. Of course, through the magic of Dojo it also works pretty well in all major browsers.

There are still lots of little details that need to be added. A means for automated password recovery quickly comes to mind, as well as more styling (what's there now is pretty close to being bare Dojo tundra), some more selective refreshing of data based on user input, better error handling (both in terms of weird user input and HTTP type errors like the dreaded 404), some friendly help for new users, and some more intelligence added to certain buttons and dialogs already within the site.

I'll post some more articles here discussing some of the key technologies and how I put them to use within the site. If anyone has any particular areas of interest, don't be afraid to speak up.

Web Site Icons

I recently got this following short article posted in the Mac-focused Kibbles & Bytes. I thought that there was probably a pretty small overlap between readers of this blog and Kibbles & Bytes, so I’m reprinting it here (with permission, of course) minus the author introduction (which would only make me blush). I hope you’ll find it interesting.

More on Favicons

Two issues ago there was an introduction to favicons. If you found it informative, read on, as there’s lots more to favicons (and more generically page icons) than was covered in that first article. In particular there are three things that should be additionally mentioned: favicons have another important capability, they have one key limitation, and they have a more standard alternative.

To really understand favicons at a deeper level it’s necessary to consider very briefly their origins. It’s clear that Microsoft hadn’t really thought through either the favicon implementation or its consequences when they first introduced favicon support in Microsoft Internet Explorer (MSIE) 5.0. There were a few obvious issues:

1. The .ICO format was very much an MS-Windows specific format. Even today it’s not too well supported on non-MS-Windows systems, and it didn’t yet have an official registered MIME type (further slowing its adoption elsewhere). Even MSIE itself didn’t support .ICO files in its Solaris, HP-UX, and Mac OS incarnations.

2. The versions of MSIE that did support favicons did something contrary to the nature of the Web itself by automatically assuming that a particular file would exist in a particular location on every server in the world. They automatically tried to download /favicon.ico whenever a user tried to set a bookmark. This sort of behavior is strictly taboo and it got lots of webmasters really upset with Microsoft.

3. Because the favicon resource would be downloaded only when users tried to set bookmarks, privacy advocates also got a little upset with Microsoft as it became theoretically possible for webmasters to track individual users who bookmarked their sites.

4. The recommended favicon <link> tag of:

    <link rel="shortcut icon" type="image/x-icon" href="/favicon.ico" />

   is logically invalid HTML because the rel attribute officially contains space-delimited items, so shortcut icon should be treated as two separate relations rather than one. It’s also already been mentioned that the MIME type listed in the type attribute was unregistered. Of course, this line could be omitted as MSIE would try to download /favicon.ico regardless; it was only necessary if an alternative location for the icon were specified.

5. When Microsoft finally registered an official MIME type for the .ICO format (image/vnd.microsoft.com) they didn’t go out of their way to support it and encourage webmasters to stop using the unofficial image/x-icon type. In fact, even today, if you’re going to be using favicons, you’re advised to use the improper form for compatibility reasons.

By now you may be thinking “what does all this have to do with additional capabilities, limitations, and alternatives?” The answer is that (as you might guess from #1 above) there are some tricks and issues that arise from the .ICO format’s MS-Windows origins, and (as you might guess from all the points above) there was some motivation to try and clean up a messy situation by introducing alternatives.

First I’ll touch on the additional capability of traditional favicons. Basically it’s the fact that the .ICO format isn’t really an icon as it may appear at first blush; it’s more of a bundle of icons. A single .ICO file can contain one or more icons of different sizes, and MS-Windows can make use of more than just the common 16×16 size. In fact, MS-Windows will happily gobble down 16×16, 32×32, and 48×48 icons and use each appropriately (16×16 for various places including the URL box and the others for various places including the desktop). In fact, if a favicon lacks larger versions, MS-Windows will take the 16×16 version and attempt to scale it up with sometimes hilarious (at least on other people’s favicons — with your own favicons it tends to be more depressing) results. I’ve also heard, but never personally verified, that certain versions of MS-Windows in certain circumstances will use both 24×24 and 64×64 favicons if available. The obvious drawback with providing more sizes is that it leads to a larger .ICO file and thus slower download times. Certainly though if you’re planning to create a favicon for your site, it’s worth making at least the 16×16, 32×32, and 48×48 versions, and Microsoft themselves recommend including at least this many.

Other browsers and other platforms have had to add some favicon support. Nowadays the 16×16 icon is supported by pretty much every graphical browser on every platform, but the support for other sizes remains weak. Of particular interest though is that Mac OS X natively supports 128×128 icons, and Vista natively supports 256×256 icons. Really forward-thinking webmasters will realize that these sizes probably also ought to be embedded into favicons sooner rather than later as they’re pretty much guaranteed to find a use, but again consider file sizes.

Next it’s important to mention the big limitation with traditional favicons: color. To make a favicon that’s guaranteed to display the same everywhere, it’s necessary to stick to the limited 4-bit, 16-color “Windows Default Palette”. This palette basically consists of white, red, yellow, blue, green, magenta, cyan, dark gray, and darker versions of the same (with “dark white” being light gray, and “dark dark gray” being black). This palette does not usually lend itself to the creation of beautiful favicons. There are two work-arounds. The first is to accept that some viewers will see your favicon as a psychedelic mess and use a larger palette; if you stick to the regular 216-color “Web Safe Palette” the vast majority of users will have no trouble. The second is to include multiple icons of different palettes within the favicon. This latter approach quickly leads to large file sizes (a favicon with both 8-bit and 24-bit color versions will not be just twice the size of the favicon with only an 8-bit version, it’ll be roughly four times the size), and it’s still not guaranteed that every system will be smart enough to pick the best color depth it can properly display.

Actually making a multi-icon favicon is a topic for another article. I’ll provide a quick tip though for advanced readers who aren’t afraid to use the Terminal.app: check out the free NetPBM utilities. The included program ppmtowinicon can create multi-icon favicons.

Now it’s finally time to get to the standard alternative. Basically all one does is to use:

 <link rel="icon" type="image/png" href="/icon.png" />

in lieu of the common shortcut icon version mentioned above. Note that this changes three things:

1. The shortcut icon changes to icon fixing the HTML logic issues with the original.

2. The type changes to image/png, a standard, platform-neutral image format with a proper MIME type. You’re also free to use GIFs rather than PNGs. Either way, they are more size-efficient than .ICO files. While it’s still prudent to stick to the Web Safe Palette in most cases (and the need for even this is reducing each day), one never has to worry about a 16-color Windows Default Palette. PNGs and GIFs are also far easier to work with, and advanced features like transparency and animation are already somewhat supported.

3. The href attribute should be set to point to an image of the appropriate type. There’s no longer a default. In fact, there’s not even a requirement that the icon be hosted on the same domain.

You can freely use both a favicon and a standard icon without worrying about making your site slower. Browsers are generally smart enough to automatically pick between the two as needed without having to download both. Usually you’d want the two versions to look fairly similar to one another, but that’s not a requirement.

The last topic I’ll mention (because its name and purpose are similar enough to cause confusion) is the somewhat related notion of domain picons. A picon is a personal icon, and a domain picon is a special icon you create that represents your entire domain. The details of how to make and use picons are clearly outside of the scope of this article, but the most important facts are that:

1. Picons don’t generally get used within your site — they get used in other places that refer to your domain in some way. For example, many forums, e-mail & news clients, mailing lists, and similar entities display domain picons with each message appropriate to the originating domain. (Locally in Massachusetts two examples that use picons include ShellTown's online mail system and Saugus' forums.)

2. There’s a global master repository of picons maintained at the Indiana University called the “Picons Archive”. Forums and other similar sites that make use of picons typically synchronize their local picon databases with this master copy periodically. Everyone is allowed to submit new picons for their own sites to this repository.

3. Picons are 48×48 images provided in both monochrome (in XBM format) and indexed color versions (in at least XPM format but also usually GIF).

4. As a consequence of #1, you can (and probably should) make a picon in addition to your other icon(s) in order to preserve your own site branding, and it normally makes sense to make your picon look like your other icon(s).

5. As another consequence of #1, providing a picon doesn’t make your site any slower to download.

That’s enough to get you started. If there’s enough interest I’ll perhaps write a little in the future on creating multi-icon favicons and/or creating picons.

Newton Technology in 2006

With the Worldwide Newton Conference going on and all the attention currently focused on the Newton, I was recently posed the following question:

Everyone keeps saying that the Newton could do things that no other PDA can. Could we get some examples?

People who haven't used the Newton tend not to recognize its capabilities, as they're not something that are really obvious from the outside. At first glance, it may appear to be just a bulky (and these days, old) PDA.

This is really a flawed analysis, though. Even though the term PDA was coined to describe the first Newton MessagePad, its current usage tends to be more associated with less capable devices that have since come onto the scene in force and took the term for their own. Both Apple and Newton, Inc. realized this themselves in the final couple years of MessagePad production, and they tried to distance themselves from the term by calling the later model MessagePads "hand-held computers".

These days people can better understand Newton devices if they compare them not to modern PDAs, but instead to modern tablet computers. The difference may be subtle, but at the heart of it is the idea that a typical modern PDA is something one uses as an extension of a desktop computer (and it has to be synchronized all the time to stay useful), while the tablet computer can itself serve more or less as a replacement to a desktop system.

The Newton devices sport a freely available, yet sophisticated development environment with a choice of modern languages. They support a wide range of hardware and protocols including 802.11g wireless networking, Bluetooth, land-line ethernet, and IrDA in addition to regular telephony (including both FAX send and receive as well as networking). They can handle extremely large memory cards, and they use these essentially as solid-state drives (they don't use hard drives). They have grayscale displays large enough to do some real work, and the entire display is touch-sensitive with support for free-form natural writing anywhere. Its handwriting recognition system is good enough for everyday use, can be tuned to one's own handwriting, and is flexible enough to handle accented characters. For those times though when writing isn't comfortable, they have a keyboard add-on that's small enough to fit in a winter coat pocket but large enough for touch-typing. It has a powerful, yet energy-efficient processor that makes for long battery life (and it can even use standard AA batteries). Its OS is fully multi-tasking, and it's capable of even playing a few movies simultaneously without losing frames.

Internally it also has some interesting concepts and capabilities. Its concept of "soups" makes novel exchange of data between applications possible. Its "Intelligent Assistant" gives it the ability to turn random, unscripted commands like call Mom or fax Darren not just work, but do the appropriate thing based upon your current location (supplying phone area codes, region codes, and prefixes as needed) and other factors (like time of day).

The combination of all of these factors makes for an extremely adaptable device.

For applications they have all the usual things expected from a PDA (like notebook, address book, calendar, etc.) but also have the sorts of full-featured apps one would expect from a tablet computer (like a word processor good enough that people have literally written novels with it, a spreadsheet app worthy of a desktop, a graphing calculator, a personal finance system, etc.). In addition to these things, they have modern Internet apps (including among others what's probably the best e-mail client I've ever seen on a hand-held device and a full graphical browser) plus some more technical apps like Telnet that (coupled with all the networking capabilities mentioned above) make the device good for checking out networks in addition to its more typical tasks.

They of course also have all the sorts of applications that people over the years have written for hand-held devices of all types; if your interest is astronomy, there's software for you; if your interest is hiking, there's software (with GPS support) for you; if your interest is photography, there's software to connect to your digital camera; if your interest is interactive fiction, there's software that will let you run all the Z-machine titles, including all the original Infocom games as well as all the newer stories.

They have a great built-in e-book parser, and in fact, the Newton book is according to some the original e-book format. This is of especial interest not just because there are large libraries of Newton books available, but because during the late '90s Newton, Inc. (before it was absorbed into Apple Computer) released the details of its Newton book packaging format to the world. The Newton book format is thus arguably an open format, and is thus open to all sorts of uses without fear of future lock-out. It's also a modern format with Unicode support that can handle many languages. I've personally been working on a Newton book reader that currently functions as an extension to Firefox (it makes it possible to read Newton books on machines running Mac OS X, Solaris, Linux, Windows XP, and everything else that supports Firefox), but any number of applications are possible.

The big thing that makes a Newton device useful isn't any one of these particular features; it's the combination of them all in a portable package. It's really got all the advantages of a typical tablet computer, but it's packed into a smaller and lighter unit, has instant-on / instant-off capabilities, was designed to even be used with just one hand while standing up, and pretty much never crashes. While these days people tend to think of PDAs as being devices to manage personal information and track meetings, Newton devices are much, much more.

Newton devices have come in many shapes and sizes. Besides the Newton MessagePad and eMate made by Apple and Newton, Inc., there are military-grade units made by Digital Ocean, a all-in-one FAX / copier station made by Siemens, and even other hand-helds made by other companies.

The later model Newton MessagePads stand out, though. Some people who've been in the computer business long enough get the ability to admire particular items not just on the merits of computer science, but on more artistic grounds. It's a little hard to explain, but some devices are more beautiful than others simply based upon the artistry in their design, and I don't mean this in a physical way based upon case mods and the like. It's a bit more like how a mathematician may find a certain formula beautiful, or a physicist may find a certain theorum beautiful. The Newton MessagePad is one such device; a person with enough background and enough exposure to it will invariably come to appreciate its elegance and beauty.

The Worldwide Newton Conference is going on right now in San Francisco as I write this, and even though I can't personally attend I'm actively following new announcments. One of particular interest is that Paul Guyot has gotten his Einstein Newton emulation project running on other hand-held devices. This means that in the future it'll be possible to essentially turn other tablet machines into Newton devices; all that's required is that they be able to run Linux. It remains to be seen though whether these devices on new hardware will ever manage to be as elegant as original Newton devices.