[Libburn] Re: Cancelling an ongoing burn. Is this dangerous ?

[Derek Foreman]

On Thu, 9 Feb 2006, scdbackup at gmx.net wrote:

> To make this useable one should probably add a member
>  .drive_id  to burn_drive_info and take care that this
> always contains a unique identifier obtained from the hardware
> access layer in some reproducible way. (However you plan to
> cope with a API that flatly does not promise anything.)
> For now one could just use the /dev/ address as in .location.
> (Nevertheless, this imposes the question what .location
> is officially good for.)

location is a unique identifier, yes.  And it's a 1:1 mapping.

I'm wondering if we should give location a bit of a promotion...

We could have a function to open a drive by location.  The location could 
be one of those HAL unique device identifiers, or it could be a /dev/sg* 
or /dev/hd*.  Then we can have legacy /dev names and some new ID system 
through the same interface.

(further, we could pass an array of these things to libburn to get our 
drive info array?)

Any comments?

Is this even what HAL is for? :)

> Elsewise my wish to directly address a drive would be
> equivalent to the wish to define a query in the HAL database
> which exactly yields one item as result.
> If the libburn API offers such a query, i would use that.

I think the front end would be responsible for dealing with the HAL 
database...

> Hehe ...  just read paragraph 4 of that article:
> "Blacklists and Whitelists".
> I am not the first one who sees the need for such. :))

Sorry if you thought I didn't like white/blacklists.  I just don't know if 
they should be managed at the libburn level.