Skip to content

HTTPS clone URL

Subversion checkout URL

You can clone with HTTPS or Subversion.

Download ZIP
Browse files

More markdownification.

  • Loading branch information...
commit 15d83fc801ca9ea55841917eaaf2ffc27137887a 1 parent 6e4f4fb
@rocky authored
Showing with 17 additions and 16 deletions.
  1. +17 −16 README.md
View
33 README.md
@@ -2,36 +2,37 @@ Device::Cdio - Perl bindings for libcdio (CD Input and Control library)
============================================================================
This adds Perl bindings for the GNU CD Input and Control library
-(libcdio) and it's ISO 9660 library (libiso9660) which are written in
-C. The library encapsulates CD-ROM reading and control and ISO 9660
+(`libcdio`) and it's ISO 9660 library (`libiso9660`) which are written
+in C. The library encapsulates CD-ROM reading and control and ISO 9660
handling. Perl programs wishing to be oblivious of the OS- and
device-dependent properties of a CD-ROM can use this library.
The encapsulation is done in two parts. The lower-level Perl interface
-creates perlcdio and perliso9660 libraries and these are generated by
+creates `perlcdio` and `perliso9660` libraries and these are generated by
SWIG.
There are also object-oriented modules that use perlcdio and
perliso9660. Although perlcdio and perliso9660 are perfectly usable on
there own, it is expected that the Device::Cdio... modules are what
-most people will use. As perlcdio and perliso9660 more closely model
+most people will use. As `perlcdio` and `perliso9660` more closely model
the C interface, it is conceivable (if unlikely) that die-hard libcdio
or libiso9660 C users who are very familiar with that interface may
use that.
It is probably possible to change the SWIG in such a way to combine
-the low-level and OO 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. Third the separation makes
-translation very straight forward to understand and maintain: first we
-get what's in C into Perl as a one-to-one translation. Then we
-implement some nice Perl 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-Perl
-translation, perlcdio or perliso9660, do result in small, but obvious
-and straightforward changes to the abstraction layer cdio.)
-
-GNU CD Imput and Control Library is rather large, and yet may yet grow
+the low-level and Object-Oriented 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. Third the
+separation makes translation very straight forward to understand and
+maintain: first we get what's in C into Perl as a one-to-one
+translation. Then we implement some nice Perl 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-Perl translation, perlcdio or perliso9660,
+do result in small, but obvious and straightforward changes to the
+abstraction layer cdio.)
+
+GNU CD Input and Control Library is rather large, and yet may yet grow
a bit. (UDF support may be on the horizon.) So what is here is
incomplete; over time it may grow to completion, depending on various
factors: e.g. whether others will help out (hint).
Please sign in to comment.
Something went wrong with that request. Please try again.