[code-review] considerations with modular XS and short namespaces

Hi there,

I need some suggestions concering the overall architecture of a module
of mine. 

I have in my CPAN-queue an XS module (Device::CDROM) that gives complete
access to a CDROM drive under Linux. This snippet shall give you a rough
idea of its interface (this one grabs the first track of an audio CD and
writes it into a WAV file):

    use Device::CDROM:
    use Fcntl qw/:seek/;

    my $cd = Device::CDROM->new( "/dev/cdrom" ) 
	or die $Device::CDROM::error;

    my $entry1 = $cd->toc_entry(1);
    my $entry2 = $cd->toc_entry(2);

    open WAV, ">track1.wav" or die $!;
    binmode WAV;
    # leave room for WAV header (44 bytes)
    seek WAV, 44, SEEK_SET;

    $cd->reset_datasize:

    for ($entry1->addr->as_lba .. $entry2->addr->as_lba-1) {
	print WAV $cd->read_audio( Device::CDROM::Addr->new(CDROM_LBA, $_), 1);
    }

    # insert WAV header suitable for this track
    seek WAV, 0, SEEK_SET;
    print WAV Device::CDROM::Format->wav_header( $cd->get_datasize );

Someone familiar with linux/cdrom.h will maybe recognize that it is
somewhat modelled after the Linux way of doing it.

However, in its current state the module would not justify its name
Device::CDROM but rather Device::CDROM::Linux as it will only run on
Linux right now. Device::CDROM::Linux isn't acceptable because there are
a number of class methods that need to be used frequently and that would
turn into

    my $adr = Device::CDROM::Linux::Addr->new(...);

Furthermore, my idea is that this module will once become portable
enough to also run on other unices (Solaris should be trivial, a little
more work needs to be done for the various BSD systems).

Ideally, I'd release a Device::CDROM that only provides those things
common to all platforms (like the various addressing modes, track layout
etc of a CDROM drive) and encapsulate the platform specific things in
other modules (such as Device::CDROM::Solaris) that need to be obtained
separately from the CPAN. The actual methods (e.g.
Device::CDROM::read_audio and all the others) become abstract methods.

My fear is that a number of these abstract methods will never have an
implementation as a particular platform might not provide a particular
functionality. 

This approach sounds clean from a software-designer's point of view.
Unfortunately, it will require me to come up with an interface that
hides the platform-specifica of a CDROM drive while at the same time
sustaining flexibility and making sure that even the most contrived and
obscure feature of the drive can be accessed and controlled. So far I
have no idea how a sane interface to a CDROM drive would have to look
like so that users of various platforms can be equally happy with it.

For those still reading and interested enough, the current state of the
module (should be fully functional on Linux) is available at

<http://www-users.rwth-aachen.de/tassilo.parseval/Device-CDROM-0.01.tar.gz>

There is lib/Device/CDROM/Cookbook.pod for those who'd like to see how
the current interface behaves in practice. The actual PODs describing
all the methods should also be rather complete.

I'd be happy about any comments, even those not strictly related to the
problems laid out above.

Tassilo
-- 
$_=q#",}])!JAPH!qq(tsuJ[{@"tnirp}3..0}_$;//::niam/s~=)]3[))_$-3(rellac(=_$({
pam{rekcahbus})(rekcah{lrePbus})(lreP{rehtonabus})!JAPH!qq(rehtona{tsuJbus#;
$_=reverse,s+(?<=sub).+q#q!'"qq.\t$&."'!#+sexisexiixesixeseg;y~\n~~dddd;eval