10 | | * The intermediate storage format will be improved where needed. |
11 | | * A format registry tracking all current formats and their abilities to save/load will be present. |
12 | | * Functionality for saving immutables and pro-things will be present. |
13 | | * Extensions and extension points will be introduced to simplify the usage of the library. |
14 | | * All the code related to persistence will conform to our code standards. |
| 10 | * The R3 format will be a Resource format, not just a Book format. This means that any kind of Resource (Book, Page, Frame etc..) could be saved in this format. |
| 11 | * Functionality for saving Immutables and ProObjects (Resources, in particular) will be present. |
| 12 | * An intermediate storage format will exist. |
| 13 | * Extensions and extension points for simplifying the usage and improving extensibility of the format. |
17 | | * Try to devise a way the SharedLoader and SharedSaver to be consistent (currently they are not - see the notes on the persistence discussion that was held on 2009-02-18). |
18 | | * Another option is to rename them so that people don't get confused by the similarity in their names. |
19 | | * See how and where the intermediate storage format will be used and improve where needed. |
20 | | * Define how properties and immutables will be persisted (a good idea is to store the immutables as string). |
| 16 | The R3 format replaces the R2 format. These are the goals of these task: |
| 17 | * The R2 format is a file format for saving a given Book. Compared to it, the R3 format is a Resource format - it should be capable of saving any given Resource. |
| 18 | |
| 19 | * This Resource-oriented format gives features that should be taken in mind when implementing it |
| 20 | : |
| 21 | * In future it should allow saving/loading any Resource - Frame, Page, Annotation. This will be very useful if we consider Frame/Page editor for example. It would be also useful for saving templates. |
| 22 | |
| 23 | * Improve machine and human readability of the format |
| 24 | : |
| 25 | * XML aspect - redesign the used XML tags to be both human and machine readable |
| 26 | . |
| 27 | * File structure - create a good and consistent structure inside the archive |
| 28 | . |
| 29 | * Data standards - what goes where |
| 30 | : |
| 31 | * XML aspect - XML should contain Immutables and metinfo. Define where does it belong in the structure |
| 32 | |
| 33 | * Binary data - define location of the binary data for each ProObject (Resources in particular) |
| 34 | . |
| 35 | * Text data - define how to handle text contents; where to store them and in what form. |
| 36 | * Define how a Resource is located and accessed (ID, local path, URL) |
| 37 | . |
| 38 | * Support caching and offline content - currently cache mechanism doesn't exust. The file format needs to support cache and ability to save online resources. |
| 39 | |
| 40 | * Caching however should be limited. In future releases we may consider GUI input for the limit, for example "100MB" |
| 41 | |
| 42 | * Make the R3 format backward compatible with R2 |
| 43 | : |
| 44 | * The application should be able to load a book in R2 format and save it to R3 format |
| 45 | . |
| 46 | * Optional - achieve saving a book in R2 format. This doesn't need to have GUI for saving in R2 but there may be a mechanism for converting R3 to R2. |
| 47 | |
| 48 | * Support of saving online content. This may not be implemented now, but in future we may have to support downloading online Resources and saving them into the book. |
| 49 | |
| 50 | * Also in the future, we need to refactor the Storage in order to implement lazy loading of Resources (and Resource preview, respectively). |
| 51 | |
| 52 | |
| 53 | == Task result == |
| 54 | * Source code |
| 55 | * Wiki content |
| 56 | |
| 57 | == Implementation idea == |
| 58 | Define a tree structure and divide the book into folders. |
| 59 | * Each resource has its own folder and contains sub-folders of its subresources. |
| 60 | * Each folder contains an XML with properties (immutables) and information for the specific resource, and information about the subresources. The folder should also contain the binary data of the resource. |
| 61 | * The book's folder has a subfolder for cache. Consider should resources have own cache directory or all should use the book cache directory. |
22 | | * @Persist allows saving of pro-things in different formats. |
23 | | * @Immutable handles persistence of immutables. |
24 | | * Both annotations are used by the savers to track what and how should be saved. |
25 | | * An annotation for things not to be persisted might be needed. |
26 | | * (Optional) Provide a class that handles all immutables coming from the JDK. |
27 | | * Provide extension points for registering formats and for savers and loaders. |
| 63 | * An annotation for entities not to be persisted might be needed. |
| 64 | * (Optional) Provide a class that handles all Immutables coming from the JDK. |