[Libcdio-devel] Thoughts about next release

[R. Bernstein]

I've been thinking about another release. The next release will some
possibly larger changes, See NEWS for the full details, but here are
some the larger changes:

- Add an object-oriented C++ wrapper.

- replace libpopt with getopt in cd-drive, cd-info, iso-info, and
  iso-read (Peter J. Creath)

- Document cd-paranoia (Peter J. Creath)*** see below ***

- Some provision for handling Rock-Ridge device numbers.

- block read routines return success if asked to read 0 blocks.

- Add cdio_eject_media_drive().

- Add more generic read_sectors() 

- Start UDF handling

- OS Support: 
    DragonFly recognized as FreeBSD, 
    MinGW better tolerated,
    GNU/Linux (and others?) LARGEFILE support

- Misc bugs: fixed bincue driver caused core dump on set_speed and 
  set_blocksize; also called NRG routine to get a list of
  cd-images. read.h didn't make sure off_t was defined. fixed bug in
  is_device() when driver_id = DRIVER_UNKNOWN or DRIVER_DEVICE.
  OSX was freeing too much in listing drives.

- NRG checking parses file. string tests were invalid on short < 4
  character filenames.


Given the largish changes and the declaration that 0.76 was a bugfix
and stability release, I'd like to start removing some of deprecated
names in the code. For example the scsi_mmc_ names which I don't think
anyone but me has ever used. And some other things marked
depricated. 

If there is a ground swell after the release it is possible to put some
of this back in. But periodically I do think it a good idea to remove
old crud and alas libcdio has a bit of it due to my ignorance of what
I'm doing. (And if folks don't provide feedback, well, it's your fault
too.)

*** cdparanoia -- 

Peter Creath did I think a phenomenal job in commenting the
CD-paranoia code library that is in libcdio. (There's no reason that
the same can't or will not be done to the stock cdparanoia
either. It's just that he as CVS access to libcdio :-)

But he has also uncovered some things may be suspicious or might even
be bugs in the cd-paranoia library. In particular if a track has
silence near where things jitter the library tends to take a long time
in reducing block size. Interestingly he discovered this in tracking
down why the CD-DA paranoia tests were failing. (So it *is* good to
have all that in there.)

The last information I had about this was he was going to contact
Monty to clarify the code and get guidance. However although some of
the suspect code is marked in as comments he was not considering
making the changes to the libcdio code base on the theory of minimal
disruption. However since by virtue of the other things ,the next
release may be a bit disruptive, perhaps it is a good idea to make
these changes so folks can get a baseline on whether this helps or
hurts matters. After all there is always the libcdio 0.76 release as
well as the stock cdparanoia code.

As before, thoughts and comments on such matters are solicited.