June 12th, 2013

Some rough ideas for a simple blog client.

Quick links:

• Wordpress' implementation of MetaWeblog.

• Wordpress' comments API via XML-RPC.

• C++ lightweight implementation of XML-RPC: Xmlrpc_c.

1.Basics

1.1.Configuration and connection

We need some dialog to configure server, user and password allowing to add as many configurations as needed. The work in Tools→Server and Tools→Client seems not to be of great use. It should look something like this:

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.

1.2.Retrieval

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.

Note 1. Persistent caching of posts may be pointless since they seem to be always retrieved in full with MetaWeblog. However, the user may want to keep his local modifications for a while (quitting TeXmacs in the meantime) before committing them to the blog, therefore we need to provide facilities to keep the local cache and update/delete it when necessary.

We should be able to retrieve comments when an extension of MetaWeblog's API is available, e.g. the comments API of WordPress.

Convention 2. We will assume that the comments API is available.

1.3.Display and edition

We use a tmfs handler which is given a handle to the local cache with the posts previously retrieved and open a buffer using it. The contents could look something like this (maybe more compact, e.g. placing the edition links next to post titles, etc.):

In a first stage we may implement a two-stage posting process. After editing the contents of a post, the user may:

1. 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.

2. Choose to update the post: we store the changes locally and the user must later “Commit” them to upload all modifications.

Note 3. Requiring the user to click “Update” is cumbersome and error-prone: one might edit a post for two hours just to see TeXmacs crash… Best would be to implement auto-save or use the facilities already in place.

1.4.Committing

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:

2.Implementation

Note 4. We already have asynchronous communication with pipes.

2.1.Communicating with the server

MetaWeblog is implemented on top of XML-RPC which is no more than XML documents encoding requests and replies being sent over HTTP. We have therefore the choice: use a well-established and tested backend like Xmlrpc_c (which depends on other libraries like Curl) or try to roll out our own (at least using something like the one-file XML parser TinyXML). Update: the requirements for the Linux autoupdater might have non-empty intersection with this (XML parsing, HTTP requests…)

In any case we will want to encapsulate this functionality in two layers:

1. One layer for the XML-RPC calls themselves. If, for instance, we use Xmlrpc_c, then this will be little more than a wrapper class providing memory management and translation of some types (e.g. TeXmacs strings to std::string, and so on). However this effectively means writing the whole interface for the protocol, which seems wasteful.

   One layer for the MetaWeblog and comments API calls. This is unavoidable and should translate server replies into e.g. Scheme lists.

2.2.Caching

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.

SQLite is another choice. Autosaving could (could it?) made be more atomic and crash recovery would work out of the box: open TeXmacs, open the blog edition tmfs handler and it will use the latest data in the database.

2.3.Commit and rollback

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.

  Remark 5. Re-downloading of content via a link in the document may be unpractical or simply ugly, since we block the whole interface. If we don't allow this, in order to provide a link for posts “Undo all changes” which works after we've modified the local copy (because the user clicked on “Update post”) we would have to have two local copies…