Loud ramblings of a Software Artisan

Saturday 7 January 2006

Digital media devices access

If you want to access your digital camera, you use a program that use libgphoto2. Now, with version 2.1.99 (upcoming 2.2) we even handle the camera that are mounted as a disk. It took us time to implement that because we didn't see the interest until we realized that people wanted to use their camera with a digital photo application, be it f-spot, gtkam, digikam, gthumb, and that the developer of said application shouldn't have to figure out the details. So now, we provide a single API for all the cameras that we know how to communicate with.

But what if you want to access your digital audio player (iPod, iRiver, Nomad Jukebox, etc)?

Some devices work as USB Mass Storage, like the small flash based players, hence do not require anything special driver.

For the iPods, there is libgpod that developers use to access the iPod private and proprietary database, there is ipod-sharp and its companion libipoddevice for those who write in C#, ipodslave of KDE developers (it is a kio-slave module) and gnupod, the Perl version.

For the Nomad Jukebox, there is libnjb, that implements the DPE protocol.

For the new iRiver and other MTP devices, there is experimental support in.... libgphoto2. Yes, you read correctly, a digital camera driver can be used. The MTP protocol is a variation of PTP (Picture Transfer Protocol, used for still image cameras), mostly pushed by Microsoft who provide a standard driver in the latest Windows XP updates. It is some sort of corruption of PTP and I think that the idea behind is to be able to control what files can put on the device, like implementing DRM. A bit like Apple does with iPod preventing iTunes users to download from the iPod the music, requiring that the music be on both the iPod and the computer, and having implemented a hackish crippling of iTunes to prevent loading some third-party plugins that allowed users to download the music off the iPod.

And I probably miss a lot.

How confusing is that ? Confusing for the developer that has to write at least four different version of code to access most of the device, and to the user that may not be able to use the application XyZ with the ACME player.

The solution it to create a library for digital audio player access the same way we have libgphoto2. One API for all the devices. That would involve a few changes in libgphoto2 to extract the PTP protocol, and give libgphoto2_port is own life, because the PTP implementation uses it. That would give the following architecture (admire the ASCII art):

libgphoto2 ---> ptp2camlib -> libptp2 <---- libaudioplayer
 \                   |            /           /    \
  \                  v           /           /      \
   \->      libgphoto2_port   <-/ <---------/        --> other drivers

Sunday 1 January 2006

gphoto2 2.1.99 "Happy New Year" released

I just released gphoto2 2.1.99. This release is required to build with libgphoto2 2.1.99 that has been released previously. One of the reason is that gphoto2 relied on some libgphoto2_port API that has changed.

gphoto2 is the command line front-end to libgphoto2.