|«« When is a Feature "Complete"?||jid3rL Wrapped in SimpleTag2 »»|
I'm Ryan Lowe, a Software Engineering graduate living in Ottawa, Canada. I like agile software development and Ruby on Rails.
I write this blog in Canadian English and don't use a spell checker. Typos happen.
» Full-time Ruby on Rails freelancer
» Full-time with Rails since May 2005
» Former committer for RadRails (now Aptana)
» I also have a few Rails side-projects in development:
1. wheretogoinTO.com Toronto nightlife
2. Hey Heads Up! TODO list and sharing
3. Layered Genealogy family history research
4. foos for foosball scoring
5. fanconcert for music fans (on hold)
Hiring Rails developers? I can telecommute by the hour from Ottawa, Canada
»» Email: rails AT ryanlowe DOT ca
Now hosted on Hey! Heads Up -- check it out!
Derek Lowe's (Ryan's older brother) words at Ryan's funeral
email@example.com no more
Forging Email Headers: Good, Bad or Ugly?
Sarcastic Dictionary (Part 1 of Many)
Twisting Rails is Risky Business
Risky Business? My Take on Early Alphas
Whoa, it's August 2007
A Postscript to "Growth at the grassroots"
»» All Blog Posts
David Heinemeier Hansson
James Duncan Davidson
Signal vs. Noise
Amy Hoy: (24)slash7
Luis de la Rosa
Two Tiered Approach for a Library
Implementing the id3v2 spec has been a lot more fun than I thought it would be. Yes, truly geeky fun ... but fun nonetheless. I'd really like to implement the whole spec, and I don't think it would be that difficult.
The only problem with implementing the whole id3v2 spec is that it's about three times more than the average programmer really needs/wants to read and write id3v2 tags. Most of the id3v2 libraries I've seen are far from complete, most only reading and writing the basic tags: Text Information, Comments and maybe Attached Picture and a few others.
So the API for a library that implements the complete spec might be a bit much for general use. It might be more useful to have a simplified API built on top of the main library that exposes much less functionality. Even better would be a library which exposes a simpler API but allows the library user to go into the more complex API if they need to.
This idea for this came from JFace, a Java GUI toolkit library built on top of SWT. JFace uses SWT to create an easier to use API for common SWT widgets, like wrapping an SWT Table with a JFace TableViewer. This saves JFace/SWT library users a lot of setup work and exposes easier to manipulate object models. Also, while using JFace, you can still get access to the underlying SWT objects to read and manipulate them.
Completely hiding complex details in a simplified API sounds like it would be much easier for me than allowing the user to dig deeper, though it may not be. If course the programmer would also have the option of just using the more complex API as well. I haven't given much thought on the specific implementation details, I'm just trying to empathize with the users of this library and what they'd want/need from it. Thoughts?Posted at August 16, 2004 at 10:06 AM EST
Last updated August 16, 2004 at 10:06 AM EST