wiki:GROUP_PERSISTENCE_R0

Version 3 (modified by gogov, 16 years ago) (diff)

--

Error: Macro BackLinksMenu(None) failed
compressed data is corrupt

Error: Macro TicketQuery(summary=GROUP_PERSISTENCE_R0, format=table, col=summary|owner|status|type|component|priority|effort|importance, rows=description|analysis_owners|analysis_reviewers|analysis_score|design_owners|design_reviewers|design_score|implementation_owners|implementation_reviewers|implementation_score|test_owners|test_reviewers|test_score|) failed
current transaction is aborted, commands ignored until end of transaction block

Analysis

Overview

This 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:

  • The base.persistence module will provide all the commons needed for persistence.
  • 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.
  • Functionality for saving Immutables and ProObjects (Resources, in particular) will be present.
  • An intermediate storage format will exist.
  • Extensions and extension points for simplifying the usage and improving extensibility of the format.

Task requirements

The R3 format replaces the R2 format. These are the goals of these task:

  • 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.
  • This Resource-oriented format gives features that should be taken in mind when implementing it

:

  • 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.
  • Improve machine and human readability of the format

:

  • XML aspect - redesign the used XML tags to be both human and machine readable

.

  • File structure - create a good and consistent structure inside the archive

.

  • Data standards - what goes where

:

  • XML aspect - XML should contain Immutables and metinfo. Define where does it belong in the structure
  • Binary data - define location of the binary data for each ProObject (Resources in particular)

.

  • Text data - define how to handle text contents; where to store them and in what form.
  • Define how a Resource is located and accessed (ID, local path, URL)

.

  • Support caching and offline content - currently cache mechanism doesn't exust. The file format needs to support cache and ability to save online resources.
  • Caching however should be limited. In future releases we may consider GUI input for the limit, for example "100MB"
  • Make the R3 format backward compatible with R2

:

  • The application should be able to load a book in R2 format and save it to R3 format

.

  • 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.
  • 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.
  • Also in the future, we need to refactor the Storage in order to implement lazy loading of Resources (and Resource preview, respectively).

Task result

  • Source code
  • Wiki content

Implementation idea

Define a tree structure and divide the book into folders.

  • Each resource has its own folder and contains sub-folders of its subresources.
  • 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.
  • The book's folder has a subfolder for cache. Consider should resources have own cache directory or all should use the book cache directory.
  • Implement the annotations that were discussed - @Persist, @Immutable (see the video of the discussion for more information on these):
    • An annotation for entities not to be persisted might be needed.
    • (Optional) Provide a class that handles all Immutables coming from the JDK.
  • Design and implement a format registry that keeps track of all formats and their features and limitations:
  • Ensure backward compatibility.
  • Consider forward compatibility in the design.

GROUP_RESOURCE_R0
GROUP_CHANGE_R0?
​http://asteasolutions.net/videos/

How to demo

  • Explain the ideas of the format.
  • Demo saving and loading of various Resources.
  • Run the tests/demos.
  • (Optional) Show the created wiki page.

Design

Implementation

Describe and link the implementation results here (from the wiki or the repository).

Testing

Place the testing results here.

Comments

Write comments for this or later revisions here.