API improvements concerning specific usecases

[elmom]

This is for you to report usecases that significantly differ from the already given ones and which you think are something that the current api doesn't work for as well as possible.

[elmom]

Usecase 1: The app gets an overview of the available drives, does *not* reserve them exclusively, allows the user a due time to choose one for operation, then tries to aquire the one chosen drive. It has to be aware that this drive might not be available any more at that time.

Usecase 2: The app scans and keeps all scanned drives open exclusively. It *hurries* to make a decision what drive to use from that list. Then it closes all drives besides one. No race condition. No doubt wether to get exclusive access to the chosen drive. One *has* exclusive access (at least libburn vs. libburn, O_EXCL is an advisory lock, my kernel locks mandatory by default. Pffft.)

These two are copied from ticket 56.

[elmom]

Usecase 3: A burning farm. It isnt' possible (I think) to have many burners working in parallel. Also, having many/any external drives, which would be likely for a burning farm, is not accounted for well enough, since that would need the ability to observe the available drives constantly and to reopen any drives that got connection problems. This should be named as Usecase 4: Efficient use of drives behind a transient connection.

[scdbackup]

Use case 1 is quite near to libburner_aquire_by_driveno() . Only said function is still cumbersome by the -still prescribed- close of libburn in order to drop all unused drives. I plan to work on that.

In case 1 the function would memorize the bus scan info in a list, shuts down libburn, lets the user choose and then re-starts with the single chosen drive. Currently it shows the bus scan, obtains only the one desired persistent drive adress, shuts down and immediately re-starts with the single pre-chosen drive. Really not much difference.

---

Use case 2 depends on what would make case 1 convenient: A call to close unused drives without shutting down libburn. I plan to work on that.

---

Use case 3 would need a libburn object which contains the operation of one drive and of which several are running in parallel. The parallel operation would be done by even more threads. This all becomes quite tricky, i guess. If really faced with that task i would rather try to control a bunch of cdrskin processes than a bunch of libburn instances in a multithreaded environment. I would build a select(2) based supervisor process which spawns the cdrskin processes and has them reporting into pipes. Then that supervisor would in some way simultaneously report the state of its children.

---

Use case 4 is a bit questionable. A transient connection to a burner would quite surely be a misburn, wouldn't it?

[elmom]

"Use case 2 depends on what would make case 1 convenient: A call to close unused drives without shutting down libburn. I plan to work on that."

Actually, see ticket 62 for this sort of thing. I 'm just finalizing a patch that improves the situation in this respect. I intend to work on this further, so please act accordingly :)

About Usecase 4: "Semi-transient" might be more appropriate. By transient I refered the fact that external, be it usb, firewire and whatnot, have a kind of transient nature in that loose connections etc. occur not so infrequently, and the most important, they might be connected after the app has been started. All this should be something that libburn reacts gracefully to. Ticket 62 is a step in the right direction.

[scdbackup]

Now you make me curious. About that use case 4 in detail and about #62.

[elmom]

burn_scan_and_grab is nice and all, but non-cdrecord like apps need a solution that doesn't grab, but instead let the user (or the lib itself, see General API [topic:6 General API improvements] for discussion about changing the api semantics) grab when the drive is needed. I plan to work on this soon, since my app could use something like this.

[scdbackup]

We now have burn_drive_info_forget() which covers use case 2. As of revision 103.

Use case 1 is still covered but burn_finish() -think- burn_initialize() - burn_drive_scan() or burn_drive_scan_and_grab().

Use case 3 is taken into respect with API rewrite plans. This can last a while.