Category: software design

The WC’s main job is to compose a new revision.

While the WC also supports merge conflict resolution, a mixed-revision base state, commit of selected parts, and many other additional features, the fundamental purpose of the WC is to help the user prepare, review and commit a set of changes which will create a new revision in the repository.

On the repository side is a similar but simpler mechanism. The FS “transaction” API, designed for programmatic rather than human users, allows the system to prepare and commit a set of changes built upon an existing revision, and commit the result as a new revision.

It is really quite important that WC modifications and FS transactions have exactly compatible semantics for the changes that they represent.

It is really quite important for the feasibility of writing higher level code such as shelving, that WC modifications can be read and written by a common, abstract, interface. That is, an interface definition which enables a ‘copy’ function to plug an input interface to an output interface and push all the changes through the pipe.

To better support these needs, changes in the WC should share an API with changes in the repository.

• WC mods API := (basic changes API) + (lots of WC-specific API)
• FS txn API := (basic changes API) + (some FS-specific API)

Is this such a crazy idea?

There are two levels at which we can perform this API refactoring. First, streamy changes via the delta editor API. The repository side already has a commit editor for input and a ‘replay’ edit-driver for output of the changes in one revision. The WC already has a commit edit-driver for output, but no editor for receiving modifications. It needs one.

Second, underneath the delta editor APIs on the FS side is a random-access API for reading and writing the modifications in a transaction: ‘txn_vtable_t’. On the WC side we should be able to use the same API as a base, minus the few FS-specific bits, and extended with lots of WC-specific features.

The common APIs for basic changes could be:

• basic changes API (streamy): delta-editor.
• basic changes API (random-access): most of root_vtable_t.

Also the WC base layer corresponds to the base revision of a FS transaction, again with a lot of WC-specific extensions. Again, common APIs should be used as the base API for reading and writing that base, extended by a WC-specific companion API. In the FS API, the same vtable is used for a rev-root as for a txn-root; each method that does not make sense on a revision returns an error at run-time. In the WC, the base layer is modifiable, albeit with its own semantics.

The common APIs for the WC base layer and the FS txn base revision could be:

• basic base-layer API (random-access): most of root_vtable_t.

There are more parts to talk about: streamy base-layer creation (‘checkout’), WC-shape/layout/viewspec API, and so on, but let’s start here.

WC streamy input/output editor APIs

• WC replay delta
  • drives a delta-editor, like ‘commit’ does
  • thin wrapper around ‘harvest_committables’ and ‘svn_client__do_commit’
  • will be used for ‘shelve’
• WC replay wc metadata
  • transmits WC-specific local-mods metadata
  • a streamy companion to wc-replay-delta
• WC delta editor
  • receives and applies modifications into the WC local-mods
  • expects unmodified WC states: no merging except trivial A-or-B merges
  • write from scratch
  • will be used for ‘unshelve’
  • use it for all existing WC modification ops (‘svn add’, ‘svn propset’, etc.)
  • what special features does it need, that existing ops expect?
    • …
  • add those features in wrappers where possible, else internally
• WC-specific metadata editor
  • applies WC-specific local-mods metadata
  • a streamy companion to WC delta editor

Definition of WC-specific local-mods metadata API:

• includes: conflicts, missing/obstructed, …

I am starting with this streamy I/O layer because I can use it to improve shelving.

The “WC replay delta” is simple and about ready to commit. Implementation of the “WC delta editor” is in progress. I will now look into designing the streamy WC metadata APIs.

Tried on-line supermarket shopping? It often takes me longer than real-life shopping, in terms of finding things. It’s great to be able to do it at all, but the product search interface is terrible. Imagine how much better it could be.

Let’s remind ourselves what it’s like walking into a current on-line supermarket to buy some sugar.

Dear shop assistant, I want to buy some sugar. You are holding up in front of me a long list of little boxes, each containing one bag of sugar, in an order that looks to me more or less random but you claim is “relevance”. Relevant to whom?, I wonder, beginning to feel you don’t understand me. Ah, there near the top is the own-brand white granulated sugar. That’s quite likely what I’ll choose. But no, that’s such a small pack. Do you have a bigger one? I beg your pardon, did you say I have to keep scrolling through the whole list and searching with my eyes to see if I can spot any other sizes that match the same description? Oh, please, won’t you just tell me?

If I were in the real shop, looking at the shelves, I would find the same products laid out sensibly: major groups from left to right, the basic cheap varieties towards the bottom, the expensive and wacky varieties at the top, and for each product type and brand the different pack sizes are next to each other.

How about showing me a photo of the real shop? I could point to what I want more quickly than searching through your list of little boxes.

Let’s try virtually walking in to the (fictional) Dyson-Apple-Google On-Line Grocery Shop.

Dear shop assistant, I want to buy some sugar. You are holding up in front of me a huge picture that looks rather like the shelves in your real shop. On the left I see the white sugars, then a column of brown sugars, then of alternative sweeteners. Towards the bottom are basic cheap varieties, and higher up I can see some wacky and expensive ones, and it looks like I would see more of those if I were to pull the picture further down. Niche products like those are in little boxes, but today I want ordinary sugar so my eyes focus on the products that occupy a larger shelf space. There! A huge bag of the own-brand white granulated sugar standing at the back of the shelf, with one of each of the smaller sizes standing in front of it. The label tells me the price per bag and per kilogram for a typical 1.5-kg bag as well as for the biggest and smallest sizes.

Today I want to order a big bag, as I won’t have to carry it home myself, so I click on the back of the shelf. The whole display changes, subtly but surely, to highlight which other brands and product lines also offer a pack size somewhere in the region of the one I selected. Maybe there is a less popular variety that I’d be interested in choosing instead. With a quick glance, I can see two alternatives. One is emphasizing it’s Fairtrade, in contrast to the product I have selected, and the other emphasizes that it’s British, both characteristics that I support in my buying choices; maybe the system has noticed that. The colour-banded price-per-kg indicators are showing me that one is considerably dearer than the own-brand while the other is only a little more.

Sold. Easy decision.

I know that developing that kind of shopping software is a lot of work. You can’t just tweak the existing little-boxes software. But, dear on-line shop assistant, that’s the kind of shop I would like to shop at.

Mozilla Thunderbird, for my needs, is one of only two viable open-source email clients — the other being Evolution — but it has woeful shortcomings. I have been wanting to express my thoughts on what is most important.

Now I am pleased to see Thunderbird’s new Community Manager Ryan Sipes is considering a new future for thunderbird and running a quick poll to “get an idea of where folks are at”. This is the answer I submitted to the main question, “What would you like to see in Thunderbird?”

In priority order:

1. Proper first-class “conversation view”. Existing plug-ins and options get somewhere towards it but aren’t nearly close enough relative to the bugginess they add.
2. Drastically clean up the UI, especially all the different search activation UIs (menu, toolbar, “quick filter”) and all the different search results displays that all look and behave infuriatingly differently.
3. Address book: separation of UI & storage. API: use CardDAV. UI: use CardBook. Storage: assume an external server as the preferred option for most modern situations; support a local store option for “traditional” self-contained installations where TB is the user’s only mail client.
4. Calendar: separation of UI & storage. API: use CalDAV. (Same considerations as for Address book.)
5. Message Filters: separation of UI & storage/service. API: use Sieve. UI: look at “Sieve Message Filters” plug-in for a basic example. Only a few open-source-y providers (e.g. FastMail) seem to be offering Sieve so far, so a local filtering service is probably going to be the more common option for now.

We should be facilitating and encouraging the use of open APIs for services such as address book, calendar and filtering.

I also think partitioning these services from the main program is an important part of preparing Thunderbird to be more portable to different environments, especially mobile.

First I had too many passwords. (And still do.) But on top of that I now have too many password managers.

My web browser, Firefox, remembers web site passwords for me, which is very helpful indeed. (On a Mac, Safari does that too and additionally offers to generate random passwords for new sites, which is even better.)

I use KeePassX as my primary password manager. As well as username and password and web site URL, I find it useful to store the associated email address and some notes, e.g. “Dormant account: I requested to close it on 2016-01-01 but sign-in still works on 2017-01-01” or “Tried to update to my new email address on 2017-01-01 but the site refused: need to contact customer support”.

Thirdly, my operating system Ubuntu has its own “Passwords and Keys” app which stores passwords and keys on behalf of other applications.

Problems:

• it’s a nuisance having to copy data between them (Firefox <-> KeePassX) when creating or changing a password
• backup is complicated: I hardly know where all three stores are, or whether they are all uniformly backed up
• three different master passwords to manage (no, don’t suggest what you’re thinking :-), and not being sure whether all three stores are similarly and sufficiently secured

Can I please have fewer password managers? OK I chose to add KeePassX into the mix, but Firefox forced its own one on me whereas I would like it to use either the operating system’s password manager or one that I designate.

I want to be able to leave comments against the settings in a GUI, like I am accustomed to doing in a plain text configuration file. Continue reading “Let Me Write Myself a Note” →