= rubycdio
== Version
:include:VERSION

== Overview
rubycdio is a Ruby interface to the CD Input and Control library
(libcdio).  You can get the source from rubyforge http://rubyforge.org/projects/rbcdio/ or at the same place as libcdio:
  ftp://ftp.gnu.org:/pub/gnu/libcdio

The rubycdio (and libcdio) libraries encapsulate CD-ROM reading and
control. Ruby programs wishing to be oblivious of the OS- and
device-dependent properties of a CD-ROM can use this library.

== Requirements

I've only tested rcdio on Ruby 1.8.4 - 1.8.6

You'll need a C compiler so the extension can be compiled when it is
installed. You'll also need libcdio
(http://www.gnu.org/software/libcdio) and it's header files installed.

One weirdness I've seen in running "gem install" is that on some OS's
like Solaris, gem assume the GNU "install" program goes by the name
"ginstall".  (I've read a report that on cygwin this was the case too:
http://www.cygwin.com/ml/cygwin/2005-10/msg00259.html )

== What's here

libcdio is rather large and yet may still grow a bit. (UDF support in
libcdio may be on the horizon.)

What is in rubycdio is incomplete; over time it may grow to completion
depending on various factors: e.g. interest, whether others help out.

Sections of libcdio that are currently missing are the (SCSI) MMC
commands, the cdparanoia library, CD-Text handling. Of the audio
controls, I put in those things that didn't require any thought. The
ISO 9660 library is pretty complete, except file "stat" information
which is at present is pretty minimal.

That said, what's in there is very usable. It contains probably more
access capabilities than what most media players that don't issue MMC
directly need.

The encapsulation by SWIG is done in two parts. The lower-level Ruby
interface is called rubycdio and is generated by SWIG.

The more object-oriented module is cdio; it is a Ruby class that uses
rubycdio. Although rubycdio is perfectly usable on its own, it is
expected that cdio is what most people will use. As rubycdio more
closely models the C interface, it is conceivable (if unlikely) that
diehard libcdio C users who are very familiar with that interface
could prefer that. Ditto for the Ruby class iso9660 the lower-level C
extension rubyiso9660.

It might be possible to change the SWIG in such a way to combine these
pieces. However there are the problems. First, I'm not that much of a
SWIG expert. Second it looks as though the resulting SWIG code would
be more complex. Note that SWIG seems to create a module while what is
in lib are classes. Third the separation makes translation very
straight forward to understand and maintain: first get what's in C
into Ruby as a one-to-one translation. Then we implement some nice
abstraction off of that. The abstraction can be modified without
having to redo the underlying translation. (But the reverse is
generally not true: usually changes to the C-to-python translation,
rubycdio, do result in small, but obvious and straightforward changes
to the abstraction layer cdio.)

There is much to be done - if you see something missing and want to
help out, please do so!

Standalone documentation is missing although many of the methods,
classes and functions have some document strings. See also the
programs in the example directory.

$Id: README,v 1.8 2007/10/13 17:11:45 rocky Exp $