libburn module for the D programming language

[Anders]

I translated libburn.h (0.3.6) into D. It works, but I didn't test it extensively so bugs are expected (typos, etc).

compile: dmd program.d libburn.d -L-lburn

program.d: import libburn; void main () { do stuff }

[Anders]

If there are any other headers you want translated, poke me on IRC (Anders, Freenode) and I'll do them... thanks

[scdbackup]

I understand this header enables libburn applications written in D. That's appealing. Do you have such a D application already ?

But: To implement sustainable support for D, we would have to repeat your work after any change of the API or we would have to do all changes in parallel. That's not very appealing. It implies the risk to have inconsistencies in the libburn package.

Better would be to have an automat which converts libburn.h into libburn.d . Automat written in C or bash, so it does not widen our system requirements for libburn development.

Question is wether to put libburn.d into libburn/ or into extras/ .

Mario: do we already have a plan for our foreign language strategy ? (Who will teach extras/java that there are new API functions burn_drive_set_buffer_waiting() and burn_drive_get_best_speed() ?)

[Anders]

There are tools to convert C headers into D, but output isn't always that great. I can keep it up to date with new versions of libburn.

It should probably go into extras, seeing as it's not used by any other stuff in the libburn package :)

I did put 10 minutes to porting the libburner program, but I ran into problems (none of which were impossible to solve)... so I didn't continue. I'll probably port it later when I have some time left.

[scdbackup]

If the generation of libburn.d can be done autmatically by a tool which does not need much extra software then it might be appropriate to put it into libburn.

The extras/ department is rather for language wrappers. I understand D can use libburn's functions directly.

About a libburner in D:

I had a glimpse on D at www.digitalmars.com/d . It might be quite unappealing to D programmers to use libburn's C API directly. Although it has object oriented semantics it still is strictly procedural C and it implies the typical risks of C programming.

So possibly it is better to write some wrapper classes around libburn's API which would allow to handle the libburn objects (i.e. libburn instance, drives, media, disc images, tracks, ...) in the usual ways of D.

That wrapper would then be used by demo programs like test/libburner and test/telltoc.