[Libburn] Reading procedure

[Tiago Cogumbreiro]

Hi list,

I've been thinking about how the reading procedure should be visible to
the user.

Derek told me the source will be an abstraction layer. One of the
sources will be the real cd drive, the others I assume are cd images, is
this it?

My proposition is that optical media, aka CD's, DVD's and all, should be
presented to the user as an array of data streams, a stream is like C's
FILE struct. It is an array because there are multitracked optical media
and the user needs to destinguish them, for example when extracting
audio tracks from a CD. But we also want to enhance the library with the
possibility for the user to implement it's own error recovery
technology, while reading the streams, this is the simple Strategy
pattern[1].
Let's call the strategy the 'data filter' (DF). What is the DF? It's
basically a hook function that we need to send a certain number of
arguments in order to provide a way to let the user correct the read
errors.

Most of you might not know, but my interest on libburn began because I
had my own cdrecording library[2] and thought it was a duplicate effort
to work on it when there was already libburn (which is more advanced).



1. The filter

In that project I implemented what I am talking about, and the handler
was designed as [3]:
/* translated to C, since it was made in Java
 * @source - the data source
 * @read - the structure responsible by reading the data from the
optical media
 * @sector - the sector you want to read from the CD
 * @ret_buff - the returned buffer
 * @ret_buff_len - the size of the returned buffer
 */
int read_frame (burn_read_source *source, read_operation *read, int
sector, char **ret_buff, int *ret_buff_len);

This type of callbacks assumes there is someone controlling which lba to
read next. Is this what we want? Is this enough flexibility for what we
need? This will open on the API a function for getting the data from a
given sector, which is READ_CD (0xBE).

2. The manager

Another way to make it extendable would be to let the user define how to
divide the media in streams. For example, an audio source being treated
as a single stream, or each session being represented as a stream, or
the user data being represented as a stream and the subs as another. In
this case the hook function would have to define how the data is
represented. This will still need the READ_CD op as public. And is
somewhat compatible with the extendability explained beforehand.

3. Usage

The usage would be something like this.

BurnReadSource *source;
source = burn_read_source_new (burn_read_media_new(),
burn_read_manager_new(), burn_read_filter_new());
BurnStream *streams[];
int i, streams_len, buff_len;
char buff[1024];

burn_read_get_streams (source, &streams, &streams_len);

for (i = 0; i < streams_len; i++)
	for (buff_len = burn_stream_read (streams[i], buff, 1024); buff_len >
0; buff_len = burn_stream_read (streams[i], buff, 1024))
		write (out, buff, 1024);
	
What are your impressions on this?

[1] - http://c2.com/cgi/wiki?StrategyPattern
[2] - http://cdmirror.sf.net/
[3] -
http://cvs.sourceforge.net/viewcvs.py/cdmirror/cdrw/src/java/cdrw/io/FrameHandler.java?view=auto