This page will serve as a holding point for in-depth implementation ideas and prototypes for the next generation of our umbrella project. [pygi]
It currently comprises of individual sections where the comprehensive sketches of developers and contributors shall evolve. A general section holds notes, questions, messages, ... [put your name when you edit or add something there]
One may put prominently marked questions, remarks or protests into the section of somebody else. They should be concise, though, and eventually point to longer explanations in the own section.
New contributors are entitled to open an own individual section. [scdbackup]
General Section:
Seems like Thomas and Lorenzo both like libdax. Let's go for it then. Shall we also change libisofs name? Under which name? I propose to do it at this release, as we have own copyright on it already. We will break compatibility but it's better to do it now then later... Thoughts? [pygi]
Thoughts of [scdbackup]
libdax+libworf could bring us in conflict with Hollywood trademarks, (Who would believe it's incidential ?) But what a nice couple. :))
How about "libisogen" ?
Matching to our pseudo-acronym excuse for "libdax" would be "libdvf" (Data Video Formatting).
[scdbackup]
thoughts of lorenzo
I would propose libidic (LIBrary for Iso Disc Image Creation). And IDIC is the foundation of Vulcan philosophy (infinite diversity in infinite combinations).. lorenzo
lorenzo's section:
--- libburn portability
I think a separate library would probably be best, since we would be able toi move most of the system-dependent functions out of the core of libburn. It would also make adding support for other operating systems more manageable. scdbackup proposes libburn/drivecmd.c with generic drive functions. He proposes different system-dependent versions of this file for all supported OS's. I am still more in favour of a separate library to separate system-dependent functions entirely out of libburn, but the system-dependent source files will avoid some of the manageability pitfalls. --- libburn important features
Whichever way this functionality is implemented, we should be able to access drives both by their actual device file names and by any links that point to those files. In other words, we should be able to access /dev/cdrw just as well as /dev/hdc. This is probably best done on the lower level, since device files are dependent on the operating system. Libburn itself shouldn't have to care about how a drive is addressed by the user or the operating system. And the last thing we need is to force the user to address a drive as 0,1,5. :) Lorenzo
Multisession appendable CD's should also be supported. [lorenzo]
--- libburn rewrite and new API
(scdbackup proposes unified libburn object as only API handle and a legacy API wrapper around that new API)
(pygi objects the duration of the legacy support period)
We should keep the old API for the development version 0.3.x, but remove it during stabilization of 0.4.x. That is, of course, unless we have so many legacy applications that we have to keep the old API in order to support them. I don't currently see that as being a problem for 0.4.x.
I am in favour of having a single consolidated libburn object. I don't think a program that uses libburn should need to directly manipulate a burn_write_opts struct for example. This could be dangerous for that program. Better to let libburn itself handle that kind of thing via functions that don't require exposure of these low-level parts of libburn. [lorenzo]
--- Media reading:
read.c will need to be entirely rewritten. There is a lot of disabled code that is using and setting things that don't even exist, especially in burn_disc_read(). The overall rewrite may take care of most of this, but I felt it should be specifically mentioned here. [lorenzo]
--- CD types:
(pygi proposes to evaluate CD types other than data and audio)
Mixed mode CD's should be supported; both audio and data on the same disc. Right now, libburn supports burning a data track and a group of audio tracks, but a CD player will try to play the data track and will play it as silence. There is a mixed mode CD format that allows the data track to be the last on the disc and still be readable by the CD-ROM drive. I think this is called CD Extra or enhanced CD.
CD-RW formatting for packet writing should be supported. This will allow a CD to be mounted writable on a Linux system via the pktcdvd devices available since kernel 2.6.10. In Windows, a 3rd-party driver is available to read and write these CD's. --- libisofs important features:
El Torito bootable images should be supported, both with and without emulation. [lorenzo]
It should be possible to create HFS hybrid volumes for use on a Mac. http://developer.apple.com/technotes/fl/fl_36.html
It should also be possible to create volumes with UDF extensions; this is the type of filesystem on a video DVD.
new api and library structure
scdbackup proposes a layered structure for the new library with the api at the top exposing a consolidated library object and the command and transport layers which control the drive at the bottom. I agree totally with this structure. It presents the application developer with a very clean generic interface to all library functions while separating out all the system-dependent stuff from the generic functionality.
new names for burner library
scdbackup proposes renaming the burner library and proposes some possible names. I have thought of a few interesting names I will post here. All of these produce very few or no Google hits.
libopticnerve (referring to the optical disc): thought it might be good for a laugh.
libkindling: fun and firy, definitely burning.
libdiscfire: try to set the disc on fire. :)
libphaser: Sure, a phaser can burn a hole in a space ship, but a narrow enough beam just might burn a CD or DVD. :)
And I personally like this one
libdax (LIBrary for Data and Audio Xfer), but it also refers to my favourite Star Trek character of all time, Jadzia Dax, who is a science officer and also drives a space ship. Drives. :) Unfortunately there is a single google hit that refers to libdax.so having something to do with ldap, but it's a single hit so may be a typo, and google.com/linux has no such hit.
project URL's
scdbackup proposes that all project URL's should stay as they are.
For now, I agree, for as long as we have the legacy libburn API. However, I propose that after the rewrite we change project URL's to reflect the new name of the project. We can redirect from libburn URL's, but if we are renaming the burner library and perhaps the umbrella project so as not to use the libburn name, we should probably change the URL's, IRC channel and other uses of the libburn name to reflect the change.
pygi's section:
--- libburn portability
SCSI access is actually the only portability issue, that's why I would propose creating an abstract library where one can easily add support for more operating systems. [pygi]
(scdbackup proposes to have an abstract function layer within libburn)
Seems like our ideas are simmilar, but why not creating a separate library with generic|abstract functions mostly for scsi access? [pygi]
(scdbackup proposes to leave the decision open until a second real transport facility emerges)
Ahm, ok. But I think we should rather decide that stuff now. I plan to implement at least freeBSD in 0.3.x dev cycle [pygi]
(lorenzo is in favor of library)
--- libburn rewrite and new API
We should strive for smaller, nicer, and cleaner api. [pygi]
(scdbackup proposes unified libburn object as only API handle and a legacy API wrapper around that new API)
So you would keep that in both development and stable cycle (0.3.x, and 0.4.x)? [pygi]
(lorenzo agrees with single API object and proposes to cancel legacy API on release of 0.4)
--- Components versioning:
Thanks to separation of components (no global bootstrap) each component will be able to uphold its own appropriate version, unlike the current way. Still to see what to do with extra things [pygi]
--- libburn CD types:
We currently support data and audio cdburning. We should probably support other types as well. Task is to identify other cd types which we want to support and list them below this section. [pygi]
(lorenzo reports of Mixed Mode)
--- libisofs Code cleanup:
Currently, there is a lot of C++ code, a lot of compiler warnings, and nasty code in general. Task is to identify such parts of code and list them below this section. [pygi]
--- Genisofs:
Genisofs must be written in 0.3.x cycle.
scdbackup's section:
--- libburn important features
(lorenzo wants -multi)
I want -tao.
We could need a .wav extractor for cdrskin. (.au is of less interest)
--- libburn rewrite and new API + libburn portability
(pygi proposes abstract SCSI library)
My idea is to have a set of generic|abstract functions which serve as internal interface to divide non-portable code from the higher portable layers. Question is, though, wether we will be able to isolate the OS semantics from those higher levels. (Classic is cdrecord where SCSI reaches up to the user addresses and the organisation structure of the flock of drives.) [scdbackup]
(pygi proposes separate library)
I plan it rather as the lowest generic layer of libburn. Next tier below will already be specific to operating systems and (virtual) hardware. Wether those dirty cellar parts will be integrated in libburn or form a separate plugin will have to be decided when we have more than one OS and transport.[scdbackup]
(pygy urges to find a decision soon)
(lorenzo is in favor of library)
Below i propose a tangible toplevel structure for a new library. In this structure there is the "Transport Layer" which is supposed to encapsulate specifics of operating system and its connection to the drive. Portability issues should therefore occur only there.
At configuration time we need to put the appropriate implementations of Command Layer and Transport Layer in place for the "make" system.
(pygi is sure wether we can talk ./configure into that task.)
Implementation of Command Layer and Transport Layer :
If somebody wants to convert the one contemporary sg-spc-sbc-mmc empire into one or two libraries, i agree. That may well be done after i converted it into a group of source modules which i understand. Or it may be done before and the benefactor tells me how it works. (I would be *so* glad !)
(pygi wants the API to be smaller, nicer, and cleaner)
Currently i am inflating the API a bit, i fear. Not for fun. On the other hand there is a lot of API functions of which i do not know the use cases. (just two: burn_track_set_isrc() , burn_session_hide_first_track() ). One will have to carefully analyse before anything can get thrown out. [scdbackup]
I am in favor of consolidating all global libburn variables into one libburn object that gets created and destroyed dynamically. This object will then be manipulated by new API methods which cover the complete set of use cases as covered by the old functions. To the rewitten API only the libburn object will be exposed - and only as opaque handle for function calls.
Nevertheless, the old API with it's exposure of internal entrails will be held available for at least one - better two - major revisions. Not so much because we have many legacy apps but to exercise and demonstrate our ways with future API changes under full sails. This old API will operate on a global libburn object handle and on dummies representing the old API structs, enums and defines.[scdbackup]
(pygi objects the duration of the legacy support period)
Let's see how fat the legacy API implementation becomes. [scdbackup]
(lorenzo agrees with single API object and proposes to cancel legacy API on release of 1.0)
I think we can agree on having a legacy API in the rewrite until the next stable major revision 1.0.
--- name of the new burn library
We should make an early decision on the name of the burner library. I believe it is best that the re-write is not called "libburn" and is only installed as "libburn" for its legacy API.
All our URLs shall stay as they are now.
Among Lorenzo's above proposals i could agree with "libphaser" and "libdax".
My own ideas for now
- libmirod (regrettably "libmir" is existing already) to refer to "mirror" (i.e. light and reflection), to spacestation "Mir" (she turned and turned and finally burned so proudly), to "Optical Disk", to "Mirrordance" (one of my favorite novels).
- libdoener (a Doener is a turkish-german roast which rotates and finally ends up in a disk shaped sandwich).
- libbeam is already in use (although not in Linux, as it seems)
- libray has 500k google hits and all seem to be typos of "library". It would be a bit near to "ray tracing", a common 3D rendering technique.
That name will reflect into the class names of our re-write. (I use "mirod" for now.)
--- Architecture of new burn library
I see four layers for now:
API layer. The representation of the library which is visible to apps. Classes: mirod_api
Logic Layer Inner representation of entities which are relevant to operation of libmirod. The API Layer uses the Logic Layer only. Classes: mirod_drivelist , mirod_drive , mirod_track , ... Global services: Signal handler common to all mirod_api instances
Command Layer
Knows what command needs to be sent to a particular drive in order
to make it perform particular actions (like eject). This layer
might be drive dependend.
Each implementation of the Command Layer has a unique command language
id number. This number can be used by mirod_cmd implementations to use
different command languages for different drives simultaneously.
Classes: mirod_cmd (in multiple versions with various helper classes)
Each implementation should have an own api class which is used
by the Logic Layer via a controlling mirod_cmd object and
its command language id number.
The command layer currently is SCSI with its subsections "spc", "sbc", "mmc". Parts of this layer are tangled with the transport layer in sg-*.c .
The transport layers currently are SCSI via either Linux sg or via FreeBSD cam. So sg-*.c is a misnamer. More correct names would be scsi-sg-linux.c and scsi-cam-freebsd.c .
The fact that both layers refer to SCSI will create confusion. The layer border as proposed here is oriented on OS portability issues. Nevertheless this coincides with the range of the SCSI specs. Command layer is *from* SCSI specs. Transport layer is *for* SCSI implementation. (Maybe transport is a misnamer ?)
Not to speak of the fact that there is no real SCSI involved with our burners.
Transport Layer
Knows how to bring a preformatted command to a particular drive.
This layer might depend on drive and on operating system.
Each implementation of the Transport Layer has a unique transport
facility id number. To be used by multi-transport mirod_trnsp
implementations.
It is not yet decided wether Command Layer controls Transport Layer
or wether both are siblings, controlled by Logic Layer.
Classes: mirod_trnsp (in multiple versions with various helper classes)
Each implementation should have an own api class which is used
by the Logic Layer via a controlling mirod_trnsp object and
its unique transport facility id number.
Global services: (eventually a representation of system and busses)
Both Layer implementation id numbers will be properties of the mirod_drive object. Each drive will be able to select its own command language and its own transport facility out of the set which is available in the particular mirod_cmd and mirod_trnsp implementation. mirod_drive will learn this during processing our replacement of burn_drive_scan().
(pygi is optimistic we can talk ./configure into preparing the appropriate implementations so they appear under the generic name.)
Lorenzo agrees with this structure.
*** end New 14 Sep ***
--- libisofs Code cleanup:
(pygi reports of sneak-in C++ and ugly code)
Two flaws found by Bart Vanherck and gcc 4.0.3 (libburn-hackers 06 Sep 2006): Over-dynamic local variables [scdbackup, bart]
/* wrong */
char child[strlen(ent->d_name) + strlen(path) + 2];
/* right */
/* Important: Make sure to free(child) before it gets forgotten as pointer
variable.
Best is to have such variables on function block level and to
have
a central function exit which cleans up all local dynamics.
Avoid dynamics if possible. They are complex and risky.
Memory leaks
and core fandangos can emerge. */
char *child= NULL;
...
child= (char *) malloc(strlen(ent->d_name) + strlen(path) + 2);
if(child==NULL)
/* PANIC ! */;
...
if(child!=NULL)
free((void *) child);
/* This is still best portable and automatically managed by the compiler.
No leaks. */ char child[APPROPIATE_MAX_SIZE];
/* The disadvantage is that one has to protect against buffer overflows */
if(strlen(text)<APPROPIATE_MAX_SIZE)
strcpy(child,text);
else
/* error handling */;
The wchar_t is a nice idea. But how to print or at least transscribe a burmese diphtong (if there is such thing at all) ? Is there a hard technical reason to use such an incompletely supported type for texts ? [scdbackup, bart] Throughout libbisofs and in part also in libburn, it is assumed that NULL == 0. Either one refuses to use symbol "NULL" or one should prepare for it
not being "0" under exotic circumstances. A mixture makes no sense. [scdbackup]
