diff --git a/doc/devel/UML/burn_source.class.violet b/doc/devel/UML/burn_source.class.violet new file mode 100644 index 0000000..f5b3654 --- /dev/null +++ b/doc/devel/UML/burn_source.class.violet @@ -0,0 +1,634 @@ + + + + + + + + + + «interface» +BurnSource + + + + + + libburn + + + + + 600.0 + 50.0 + + + + + + + + 612.4370214406964 + 81.3237865499184 + + + + + + + + Ecma119Source + + + + + + 604.1172144213822 + 242.59825146055505 + + + + + + + + WriterState + + + + + + 861.1034292438676 + 244.31119796826698 + + + + + + + + FilesWriterSt + + + + + + 984.2531292100068 + 359.95094883087904 + + + + + + + + VolDescWriterSt + + + + + + 717.2457054234224 + 357.4185959653686 + + + + + + + + DirInfoWriterSt + + + + + + 854.6043620021998 + 355.85097462036043 + + + + + + + + Ecma119Image + + + + + + 392.3294860655768 + 240.39714472372754 + + + + + + + + The context data for image burn sources, contains +references to the tree, creation options... + + + + + + 261.45257180386454 + 85.80450046553075 + + + + + + + + Ecma119Node + + + + + + 291.8219414851778 + 612.806815288254 + + + + + + + + init() +write_voldesc() +write_dir_info() + + + + + «interface» +ImageWriter + + + + + + 401.9520048709197 + 344.8700633507891 + + + + + + + + JolietNode + + + + + + 409.0872475609359 + 614.8200784564067 + + + + + + + + FileRegistry + + + + + + 718.2810974616434 + 459.0339463910502 + + + + + + + + Ecma119Writer + + + + + + 273.51763645062584 + 489.95333138112096 + + + + + + + + JolietWriter + + + + + + 404.3304191009253 + 485.1965029211101 + + + + + + + + ElToritoWriter + + + + + + 512.5482665661723 + 485.19650292111 + + + + + + + + size : off_t +block : uint32_t + + + + + IsoFile + + + + + + 720.659511691649 + 568.4410009713001 + + + + + + + + «interface» +Stream + + + + + + 909.7434429770816 + 580.3330721213274 + + + + + + + + ImageWriter goal is to encapsulate the output +of image blocks related to one "specification", +i.e. we will have an implementation for ECMA-119/RR, +other for Joliet... + +Note that having different implementations for things that +need to be written in the same block has no utility, i.e. RR +and ECMA-119 must share its Writer implementation. + +Note also that while this provides considerable encapsulation +the provided abstraction is really partial: In the relation +with WriterState the encapsulation is quite good, each +concrete state know what method to call here (notice that +this interface is also quite coupled with state). However, +with respect to Ecma119Image the abstration only refers +to implementation, as the Ecma119Image needs to know +about the ImageWriter implementations. This can't be +avoided, as Ecma119Image has to be responsible of the +instantation in the correct order and following the user +needs. + + + + + + + + 2.3784142300054896 + 160.54296052536733 + + + + + + + + The files are registered into the file registry, that will take care +about the written of content. + + + + + + 286.59891471565567 + 708.7674405416217 + + + + + + + + Each state will invoque property method in each of +the ImageWriters. Some writers can return without +outputting anything. It is possible that when dealing +with UDF or other specification we would need new +states and methods in ImageWriter + + + + + + 765.8493820617523 + 132.001989765302 + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + * + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + * + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + diff --git a/doc/devel/UML/burn_source.png b/doc/devel/UML/burn_source.png new file mode 100644 index 0000000..5786ab2 Binary files /dev/null and b/doc/devel/UML/burn_source.png differ