First a summary of the important things what I learned from the previous
- sqlite is weakly typed and uses Unicode per default (which
is necessary to store UTF-8 XHTML chunks)
- As it is capable of transaction, DB schema migrations can be
handled safely within one transaction.
- Exclusive DB lock for the accessing application (no external
modification as long as Liferea has it opened for reading).
This already solves a lot of problems. So given that all existing data
types currently stored in the XML cache:
- decimal signed and unsigned numbers
- Unix timestamps
- UTF-8 strings
- UTF-8 XHMTL chunks
can be expressed in sqlite the next question for me is about the access
pattern. How is data loaded and written to the DB backend?
Here is what I imagine:
-> displaying items in the item list GtkTreeView
-> displaying item(s) in the HTML view
-> displaying feeds in the feed list GtkTreeView
-> displaying feed info in the HTML view
the necessary information is gathered by a single DB request whose
results are then processed/rendered/merged with the respective view. The
cause of the update may be a user action or an non-interactive update
callback (due to new download, vfolder rules, cache drops,...).
Now for the user interactions:
-> adding/removing/renaming... one or more subscription
-> changing the state of all items of a feed
-> changing the state of an item
Using the current selection these can actions also can be transformed to
single DB access.
For each of those renderings or modifications no feed/item data is kept
in memory. The only input for those DB requests is the current internal
state of item list and feed list.
Is this reasonable?