June 12th, 2013 |
Quick links:
We need some dialog to configure server, user and password allowing to
add as many configurations as needed. The work in
Connection with any given config may be performed either with the previous dialog or via menu items (we must still heed the preference “Complex actions through menus”).
Some sort of ping should be executed to test the config after accepting it.
We should retrieve the latest posts
(configurable option) and store them in a temporary local cache. We
will need to be able to selectively re-read or update items in this
cache.
We should be able to retrieve comments when an extension of
We use a
Title of post #1 (4 comments)
Blah blah contents and stuff.
Author name, (date, time)
Title of post #2 (2 comments)
Blah blah contents and stuff.
Author name, (date, time)
Title of post #3 (2 comments)
Title of post #4 (2 comments)
Posts 1..4 of 76, retrieved on Thu. 28 Nov. 2013 at 23:56 GMT+1
In a first stage we may implement a two-stage posting process. After editing the contents of a post, the user may:
Undo all his actions: we replace the contents with the cached copy. Does this make any sense? After all the user may just undo the editions in the document.
Choose to update the post: we store the changes locally and the user must later “Commit” them to upload all modifications.
This basically sucks.
Committing is again a two-stage process. Clicking the appropriate menu item / link on the page pops up a dialog with a simplified list of changes for review, together with buttons “Ok”, “Cancel”, “Revert all”, “Keep local copy for later”. The dialog should look something like this:
In any case we will want to encapsulate this functionality in two layers:
One layer for the
One layer for the
The cache could in principle be a TeXmacs document. This would instantly provide auto-saving (following the user preferences) and crash recovery, and would greatly simplify the posting interface (no need for an “update” button and builtin undo management). However it could get slow if there are many posts and comments to store and parse (needs testing). We would need dedicated tags to store the metadata and status flags for each item.
Keeping the local copy of the changes might not be enough to easily perform these tasks. We might also need to keep a list of the actions to be performed on the server: “delete this comment”, “update this post”, etc.
A simple approach might be to add a status flag to each entry in the local cache with three values: pristine, modifed and deleted. This is enough to:
Decide which items must be acted upon and do so.
Rollback to the contents of the server: simply re-download the content.