[Libburn] Re: current status

[scdbackup at gmx.net]

Hi,

> I just wanted to know [...] how usable libburn is.

As far as data tracks are concerned, the burner part runs
stable in everyday situations. Within its restrictions
it allows to build applications which are user safe.
(The application should implement signal handling with a
 proper drive release sequence if it has to expect to get
 aborted. See below: lack of reset feature.)


Known restrictions resp. deficiencies in comparison to cdrecord :

- libburn needs to know the track size in advance.
  Either by examination of the track source on disk, or by
  explizit setting the size from the calling application.

- No multi-session.

- The current versions cannot avoid to touch bad drives which
  reside in the same system as the drive which you want to use
  for burning. That might render libburn unusable if the bad
  drive makes it stall.
  (A proposal to make this avoidable is pending.)

- There are no means to reset a busy drive. One must avoid
  leaving a drive busy. (Or one has to keep cdrecord ready for
  its option -abort.)


> Is it still actively developed?

It is not dead, but one needs a certain patience and/or
the will to temporarily fork an own version in order to
get running an application which has to fulfill predefined
goals.

I want a command line driven alternative to certain
cdrecord gestures for data backup purposes. libburn imposed
three obstacles of which i could remove two myself. One of
the solutions meanwhile found its way into libburn's CVS, 
the other is (as said) pending. Still open is the wish to
write a track with open end (i.e. like: cdrecord -tao ... - ).


> I was thinking to use
> libburn or nautilus-burn in one of my applications, just can't decide
> which one, yet.

My own motivation is to have two independend ways of CD burning
for my backup tool.
Accordingly i would advise you to design your application in a
way that it can use both libraries.


Have a nice day :)

Thomas