[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