From the Mind of Trevor Stone

Through an Internet rabbit hole this evening I was reminded of a big piece of Boulder business history and big (at the time) data processing.

As a kid, I was vaguely aware of a bulk mailing company called "Neodata" because (a) the Centennial Middle School computer club would occasionally feed students pizza while we organized Boulder Parks & Rec catalogs into big mail sacks that would go to every house in Boulder, and I think someone from Neodata was involved and (b) I'd noticed that subscription cards for Sesame Street Magazine had an address of "123 Sesame Street / Boulder, CO 80322", which was odd because I knew Boulder didn't have a Sesame St., so my mom explained that Neodata processed subscriptions for all sorts of magazines in Boulder and they had a whole zip code to themselves, so any street address could be used.

My rabbit hole led me to a lot of Neodata-related photos from the Boulder Carnegie Library for local history. I hadn't realized that Neodata's roots in Boulder go all the way back to 1949, when Esquire Magazine opened an office in Boulder to handle magazine subscriptions for Esquire and Coronet. (Yes, it took a whole building full of workers to handle subscriptions for a couple magazines back then.) Their original office was at 13th St. and Portland Pl., across from Casey Middle School. They later built a warehouse on Walnut east of 30th St., perhaps to make it easy to put mail bags on the train. (Based on this photo, it might be the building now occupied by The Spot rock climbing gym and the Brewers Association.)

In 1963, Esquire and The Nielsen Company created Neodata Services, Inc. to provide computerized magazine subscription services. They would've had some of the first computers in Boulder, and they were in town long before IBM. (The Bureau of Standards, now NIST, might've had an earlier computer.) Judging by the photos they might also have been one of Boulder's top employers for women in the 1950s. Fans of punch card systems, magnetic tape reels, and other old office technology will enjoy the collection too.

I hadn't heard anything about Neodata since some time in the 1990s. It turns out that they were purchased by EDS (the IT company founded by Ross Perot) and reorganized with several other EDS business units into "Centrobe" in 1997. A business profile in early 2000 notes that Centrobe processed 3% of all USPS mail and had offices in Louisville and Longmont; I think their Boulder office had closed. EDS was purchased by HP in 2007 and Centrobe got merged into Hewlett Packard Enterprise. I haven't been able to follow the trail further from the public Internet. Does HP still have a magazine subscription services department? Do they still operate in Boulder County?

After playing around a bit with mh's support for mbox, I realized it doesn't meet my needs. For instance, you can't refile from one mbox to another, which means it really won't work for my Pluggable MUA plan of accessing my email.

On Saturday, I therefore decided to start working on what I'll call pmh, or perhaps pclmi ("pickle me") for Perl Command Line Mail Interface. I googled perl email and discovered there's More Than One Way To Do It. The first hit was The Evolution of Perl Email Handling, written by Simon Cozens, the main author of the Email::* modules. The Email:: approach is to be as simple as possible, but no simpler. It's small, lightweight, and easy to understand without flipping back and forth between manual pages. I implemented crude but functional versions of scan and show. Unfortunately, Email::Folder hides too much in its API. Email::Folder only presents an iterator, no random access. However, the mh-style approach depends on random access, so you can do scan and then show 1234.

This evening, I tried the older, more featurefull, and more complicated approach, Mail::Box. I converted my test commands to the Mail::Box API with its random message access and discovered something interesting:

Using Email::*, showing message 1 of 1920 takes about 8 seconds. Showing message 1920 takes about 8 seconds.
Using Mail::*, showing message 1 of 1920 takes about 14 seconds. Showing message 1920 also takes about 14 seconds.

It would seem that the random access API afforded by Mail::Box doesn't buy anything when accessing mail in mbox format. (I haven't yet tried maildir.) Furthermore, a scan with Email::Folder on the 1920 message box takes 11 seconds and starts working immediately, while using Mail::Box it takes 45 seconds, including an extended pause at the beginning.

8 seconds is an unacceptably long amount of time to wait to see a message in a (for me) modestly sized folder (and yet, mutt changes to a folder and shows a message much quicker than that...). I may be forced to abandon the every operation is a separate process mantra and shift to a command interpreter which can hang on to folder contents. Alternatives include coming up with a crafty indexing approach which can be abstracted as a folder (view), or trying my performance luck with the javax.mail API.