legacy/libisoburn/trunk/test/xorriso.txt

50 lines
2.3 KiB
Plaintext
Raw Normal View History

2007-10-12 20:39:29 +00:00
--------------------------------------------------------------------------
The architecture of the xorriso application is planned as follows:
The main program module creates a xorriso object, calls startup-file reading,
argument reading, and eventual dialog shell function.
The xorriso class module implements the xorriso state object and above three
main functions. These functions rely on a common interpreter of a list of
words as described in man xorriso, paragraph "Command processing".
The list may contain more than one command with its parameters. It is intended
to be either the list of program arguments or a list parsed from a single
input line.
The interpreter converts the words command-wise into suitable parameters
for an actor function which performs the command's action resp. a setter
function which brings the command's setting into effect. The interpreter then
calls this function immediately and synchronously.
These option functions form a well documented API which may be used by
interpreters of things other than words. E.g. by a GUI module or as libxorriso.
xorriso will encapsulate libisoburn, libisofs and libburn. Although i know
it is not popular, i propose to link it with the object files of those
libraries and not against external library objects.
(Did i watch somebody having an allergy against external programs ?
I got an allergy against .so . My immune system mistakes them for .DLL .)
>>> currently a stub for xorriso is derived from the source of scdbackup_askme.
--------------------------------------------------------------------------
Emerging man page is now in text/xorriso.1
2007-10-12 20:39:29 +00:00
( Needs enhancement in libisofs:
-cut_out disk_path startbyte bytecount iso_rr_path
Cut out a piece of file disk_path and insert it into the ISO
image under the given iso_rr_path.
This is advised for files > 2 GiB - 2 KiB if you are not
certain that all your systems with ISO filesystem driver can
handle such large files. Depending on the libisofs
implementation, files of larger size may generate SORRY
events if they are processed uncut.
When reading those files pieces from media, you will have to
concatenate them in the correct sequence:
cat /mnt/file_part1 /mnt/file_part2 > $HOME/file
)