Dan Scott has posted a request for comments on his blog today concerning a Super-alpha MARC package for PHP that he's been working up. He's asking readers for their opinions of if they'd use it or not.

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?

He talks about the development of the package (from the php-marc package) and some of the differences between the two. Among them are:

• System requirements
• Functionality (different means to the same end)
• Error handling
• Tests (unit testing files included)

Dan Scott has posted a request for comments on his blog today concerning a Super-alpha MARC package for PHP that he's been working up. He's asking readers for their opinions of if they'd use it or not.

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?

He talks about the development of the package (from the php-marc package) and some of the differences between the two. Among them are:

• System requirements
• Functionality (different means to the same end)
• Error handling
• Tests (unit testing files included)