Coffee|Code : Dan Scott

Earlier in the month I asked for feedback on the super-alpha MARC package for PHP. Most of the responses I received were along the lines of "Sounds great!" but there hasn't been much in the way of real suggestions for improvement. In the mean time, I've figured out (with Lukas and Pierre's assistance, merci beaucoup) how to make use of PEAR::ErrorStack for error handling. I've also decided to split my linked-list-in-PHP implementation into a separate package; first, because it might be useful for someone else; second, because as a separate package the PHP gurus that care deeply about things like returning references can go over it with a fine-toothed comb without having to worry about all of the MARC stuff.

So, once again I'm interested in your comments -- but this time I'm looking for comments on two different packages:

• Structure_Linked_List - implements a doubly-linked list
• File_MARC - reads and generates MARC formatted records

Next steps are to build real PEAR packages for these beasties and put together PEAR proposals for consideration of the community... but don't feel that you have to wait until the proposal to offer any suggestions!

I will put up .phps versions of the examples for each package, but for some reason I'm having problems getting my host to accept my .htaccess file... look for an update on the respective pages after I contact my hosting support team.

Amber watched her first film in a real theatre(1) this morning. She had slept straight through You, Me, and Dupree two weeks ago, but insisted on paying attention to today's showing of Talladega Nights: The Legend of Ricky Bobby. Maybe it was the NASCAR action, maybe it was the redneck hollering; maybe it was the unrelenting onslaught of product placements, or maybe it was simply Wil Ferrell's kind, gentle, and let's not kid ourselves, downright handsome face blown up to twenty-foot dimensions, but she was riveted to that screen.

I'm glad we're taking the time to expose her to these cultural influences early; so many people waste their children's crucial first formative months with mindless noise like Beethoven. When my darling baby girl grows up, she's going to be able to say with pride "My daddy done taken me to that there picture show when I was nothing but a squirt in a diaper -- soooo-EEEEE!".

1. A local cinema offers a bi-weekly screening of a popular film in a baby-friendly environment. They turn down the volume, leave the lights on dim, provide changing tables and diapers, and nobody minds if the babies cry or if moms are breastfeeding during the flick. It's pretty cool. If the gods are kind, maybe Beerfest will be up for viewing in a month or two...

Although my fingers are pretty sore after writing this entry.

Over the weekend, our household participated in the Orillia Triathlon, Duathlon and Try-a-Tri. A couple of weeks ago, Lynn decided that she was ready to jump back into the triathlon waters with a Try-a-Tri (350m swim, 10k bike, 2.5k run). The Orillia event also happened to be the provincial athletic championships where triathlon clubs could compete for an infusion of cash based on their participation rate, and given that this was the Nickel City Triathlon Team's first year of existence Lynn wanted to support our team and ensure that Sudbury would be known for more than mining. Aside: our team actually came in third for participation points at the event, so we won $300 for the club -- yay team!

Lost in the wake of her enthusiasm, I decided a few days before the event to join her: partially because I wanted to support the team in more than just a "I paid my membership fee and got a Web site going" way; partially because I wanted to cheer Lynn on; and partially because I totally screwed up the date that our friends were hosting a going-away barbecue and I suddenly found myself with a free day. So, because someone was going to have to look after Amber during Lynn's race, I was going to have to choose either the sprint triathlon or duathlon for my own event. Not having put much time into swimming practice over the summer (and by "not much time" I meant three swims of over 250m), and knowing that I would have to breast stroke the swim portion and face the ridicule of my fellow athletes, I opted for the duathlon instead.

Okay, I've been working on this project (let's call it PEAR_MARC, although it's not an official PEAR project yet) in my spare moments over the past month or two. It's a new PHP package for working with MARC records. The package tries to follow the PEAR project standards (coding, documentation, error handlers, etc) in the hopes that, when I put a proposal forward, it will be accepted as a true PEAR package. For now, I'm most interested in getting feedback from coders for libraries on the usability of the API that I've designed -- is it easy enough to use and does it offer the functionality that you require for your day-to-day work?

The core MARC decoding routine was taken from the php-marc package that Christoffer Landtman coded for the Emilda open source library management system. The decoding routine was based on the algorithm contained in Perl's MARC::Record package. Christoffer generously relicensed php-marc under an LGPL license so that I could use it as the basis of a (hopefully, eventually) official PEAR package. PEAR_MARC itself will therefore be licensed under LGPL.

Some of the major differences that users will see between php-marc and PEAR_MARC are:

• System requirements: php-marc requires PHP 4 or 5, while PEAR_MARC requires PHP 5 due to my desire to offer a relatively clean OO structure.
• API: php-marc was based closely on Perl's MARC::Record API, while with PEAR_MARC I've created a new API from the ground up that is hopefully cleaner, more intuitive where possible, and more transparent where necessary
• Class hierarchy: php-marc offers one major class that contained all of the methods, with different subclasses used as constructors for different MARC sources (files, strings, YAZ). PEAR_MARC is designed with different classes representing subfields, data fields, control fields, and entire records, with just one class representing all MARC sources.
• Functionality: php-marc fields and subfields are based on arrays, which results in some interesting limitations (for example, when you add a subfield in php-marc it is always added to the end of the existing subfields). PEAR_MARC is based on a linked list structure, which enables the user to add fields and subfields at any point in the list.
• Error handling: php-marc implemented warn() and croak() methods as a clone of Perl's API. PEAR::MARC relies on PEAR_ErrorStack as a standard that conforms to the PEAR project requirements.
• Performance: php-marc offers a class, MARC_Index, that claims to be incredibly fast but which can only be used for read-only operations. I haven't benchmarked PEAR_MARC yet, but I have to assume that it will appear sluggish for read-only operations and would probably lag php-marc in performance for operations that add, modify, or delete subfields. It might be possible to create a class similar to MARC_Index that offers read-only operations with the same API as PEAR_MARC and simply make it an option passed in to the constructor. At this point... not a priority.
• Tests: PEAR_MARC includes a number of unit tests that have already been helpful in ensuring that the classes operate correctly. php-marc currently offers no unit test suite; however, it is used in production by emilda so it is arguably well-tested in practice

You can find the latest version of the PEAR_MARC package posted at http://marc.coffeecode.net. Please append any comments as replies to this post, or email me at dan@coffeecode.net.