Changes between Version 2 and Version 3 of GROUP_PERSISTENCE_R0


Ignore:
Timestamp:
04/13/09 14:11:40 (16 years ago)
Author:
gogov
Comment:

--

Legend:

Unmodified
Added
Removed
Modified
  • GROUP_PERSISTENCE_R0

    v2 v3  
    66 
    77== Overview == 
    8 This group of tasks is about improving the base.persistence module and providing a well-designed, easily usable and extensible persistence library. After this task is complete, the following will be true: 
     8This group of tasks is about improving the base.persistence module and providing the new R3 resource format. After this task is complete, the following will be true: 
    99 * The base.persistence module will provide all the commons needed for persistence. 
    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. 
    1514 
    1615== Task requirements == 
    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). 
     16The 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 == 
     58Define 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. 
    2162 * Implement the annotations that were discussed - @Persist, @Immutable (see the video of the discussion for more information on these): 
    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. 
    2865 * Design and implement a format registry that keeps track of all formats and their features and limitations: 
    2966  * see [wiki:BASE_PERSISTENCE_FORMAT_REGISTRY_R0] for more ideas on that. 
    3067 * Ensure backward compatibility. 
    31  * Consider forwards compatibility in the design. 
    32  * (Optional) Provide a wiki page - [wiki:BASE_PERSISTENCE] with detailed documentation on the library created so that everyone can easily get into it. 
    33  
    34 == Task result == 
    35  * Source code 
    36  * (Optional) Wiki page 
    37  
    38 == Implementation idea == 
    39  Watch the design discussion on persistence to get an idea of how things should be done. 
     68 * Consider forward compatibility in the design. 
    4069 
    4170== Related == 
    42 [wiki:BASE_PERSISTENCE_COMMONS_R0][[BR]] 
    43 [wiki:BASE_PERSISTENCE_INTERMEDIATE_STORAGE_R0][[BR]] 
    44 [wiki:BASE_PERSISTENCE_FORMAT_REGISTRY_R0][[BR]] 
    45 [wiki:BASE_PERSISTENCE_PROPERTY_FORMAT_R0][[BR]] 
    46 [wiki:BASE_PERSISTENCE_IMMUTABLES_R0][[BR]] 
    47 [wiki:BASE_PERSISTENCE_FORMAT_POINT_R0][[BR]] 
     71[wiki:GROUP_RESOURCE_R0][[BR]] 
     72[wiki:GROUP_CHANGE_R0][[BR]] 
    4873http://asteasolutions.net/videos/ 
    4974 
    5075== How to demo == 
    51   * Explain the ideas of the library. 
    52   * Show the source code. 
    53   * Run the tests/demos. 
    54   * (Optional) Show the created wiki page. 
     76 * Explain the ideas of the format. 
     77 * Demo saving and loading of various Resources.  
     78 * Run the tests/demos. 
     79 * (Optional) Show the created wiki page. 
    5580 
    5681= Design = 
    57 The org.sophie2.base.persistence module will provide an extension point for formats via the BasePersistenceModule class. Each format should inherit PersistFormat and implement its abstract methods. Two additional methods will be provided - getSaver(Class<T extends Resource> saverClass) which returns a saver for a given type of resource and createLoader(Class<T extends Resource> loaderClass) which returns a loader for each resource of type T. Saving and loading of books should be implemented via the getSaver(Book.class) and createLoader(Book.class) methods. A default saver and loader might be provided in the future. The format registry should be easy to implement - it just has to track the registered extensions. 
    5882 
    5983= Implementation =