Changes between Version 25 and Version 26 of liburnia

Timestamp:

09/10/06 03:07:49 (7 years ago)

Author:

scdbackup

Comment:

--

liburnia

@@ -1 @@
--------------------------------------------------------------------------------------
-
-The structure of this wiki is getting out of hand. Shall we convert it into a ticket
-or into a discussion ? Or shall we divide it into personal areas where each
-participant develops an own plan, merrily copying text and ideas from the plans
-of the others. That would keep the single plans consistent - if they are ripe enough.
+
+This is my proposal for a new structure of this wiki. It is a rearranged version
+of what eveolved up to now. I still have the old text on disk (and we will probably
+be able to roll back anyway.) [scdbackup]
+
+------------------------------------------------------------------------------
+
+The structure of this wiki is getting out of hand. 
+hall we convert it into a ticket or into a discussion ?
+
+Or shall we divide it into personal areas where each participant develops
+an own plan, merrily copying text and ideas from the plans
+of the others. That would keep the single plans consistent - if they are
+ripe enough.
 The hope is that the plans find nearer together and that the last discrepancies
 can be solved in final discussions on very narrow topics.
@@ -10 +18 @@
 
 Ok, personal areas is fine. Are you willing to create such areas on this wiki and copy&paste things where they should belong? [pygi]
--------------------------------------------------------------------------------------
-
-This page will serve as a holding point for in-depth implementation ideas and prototypes for the next generation of our umbrella project. [put your name when you edit or add something]
-
-[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]
+
+------------------------------------------------------------------------------
+
+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:
+
+(still empty)
+
+------------------------------------------------------------------------------
+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.
+
+
+--- 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. 
+
+--- libisofs important features:
+
+El Torito bootable images should be supported, both with and without emulation.
+[lorenzo]
+
+------------------------------------------------------------------------------
+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 portability
+
+(pygi proposes abstract SCSI library) 
 
 My idea is to have a set of generic|abstract functions which serve as internal
@@ -26 +181 @@
 addresses and the organasition structure of the flock of drives.) [scdbackup]
 
-Seems like our ideas are simmilar, but why not creating a separate library with generic|abstract functions mostly for scsi access? [pygi]
+(pygi proposes separate library)
 
 I plan it rather as the lowest generic layer of libburn. Next tier below will
@@ -34 +189 @@
 and transport.[scdbackup] 
 
-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]
-
-I think a separate library would probably be best, since we would be able to 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.
-
-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
-
-API:
-
-We should strive for smaller, nicer, and cleaner api. [pygi]
+(pygy urges to find a decision soon)
+(lorenzo is in favor of library)
+
+--- 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
 
 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]
-
-Currently 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.
+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]
-
-One or two major revisions?! You do understand our versioning scheme, right? 
-So you would keep that in both development and stable cycle (0.3.x, and 0.4.x)?
-Ah. [pygi] Let's see how fat the legacy API implementation becomes. [scdbackup]
-
-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]
-
-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]
-
-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:
-
-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]
-
-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. 
-
-Multisession appendable CD's should also be supported. [lorenzo]
-
-[-libburn-]
-
-[libisofs]
-
-El Torito: 
-
-El Torito bootable images should be supported, both with and without emulation.
-[lorenzo]
-
-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]
+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 0.4)
+
+I think we can agree on having a legacy API in the rewrite until
+the next stable major revision 0.4.
+
+--- 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):
@@ -139 +274 @@
 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]
-
-Genisofs:
-
-Genisofs must be written in 0.3.x cycle.
-
-[-libisofs-]