[Libburn] New libisofs, part 1

Steven Van Impe steven.vanimpe at telenet.be
Mon Mar 21 03:13:02 PST 2005


> How do I go about putting this into libburn so I can test it?

Well, you can't without the writer part :).

>  A better
> approach (rather than a tarball) is to make a diff of the tree (or if
> you have cvs access, use cvs diff -u) and send that out.

That was the plan. But would that be a good idea if only part of the
library is rewritten ?

>   Anyway, I'd
> like to try this out and get working on the writer so we can fix that
> issue on ppc of in-memory ISO's not writing to CD correctly.  Thanks in
> advance!

My plan was to do the writer as well before I sent out a first version.
But appearantly, my professors don't really care about code (they
consider it a bit inferior, so I don't have to send in any code, I don't
even have to write it) and expect me to write quite a big report instead
(containing only a minimum of code). 
So right now, I can't really afford to write any more code and should
start and finish that report first (which is due by the end of may).
That's why I decided to just send out what I have so far, to have it
reviewed.

The current code only collects data and builds a volume and tree.
So what I'd like to know is:
 - Does the code work properly ? I haven't had time to test anything,
except for the tricky utility functions.
 - Is it OK feature-wise ? Is there stuff left out that needs to go in
or vice-versa ?
 - I had to make some decisions on stuff that wasn't defined in any
standard (like how to go from input to file indentifier), do you agree
with the decisions I made here, or should they be changed (details on
what and where are in the comments) ?
 - Is the code portable enough ? I'm no expert on this, but as far as I
know, I've used only POSIX functions.

Obviously, I'm still willing to do the writer part as well, but that'll
have to wait a bit.



More information about the libburn mailing list