coffee, black   no sugar

One of the things Dare and Yaron got right in the recent discussion about Web3S and APP (see here and here): time is ripe for a PATCH method.

Why is that? You can compare the current mechanisms and protocol for editing the web to the state of team work in programming twenty years ago. In the eighties (as I recollect them, your mileage may vary) people developing on PCs migrated from using plain text files to SCCS, or even RCS. This followed the more mature working style of people on PCs and also multi-person projects became more common. Collaboration needed tools.

Unix Patch

The genius Larry Wall came up with patch and that tool is the working brain behind everything from RCS to CVS to Subversion, Perforce and ClearCase. You name it. It is immensely useful. You know it. But in the light of recent discussion it might be worth restating why patch is so great.

What (for me) is at the core of diff/patch is what I call SMUC (Smallest Meaningful Unit of Change). For programming languages which almost all use a single command per line of code, treating a text line as your SMUC make sense. Add to three simples rules:

1. Changes on adjacent lines get aggregated to a block.
2. Either all changes in a file get applied or none.
3. Reformatting a complete file is the last thing you want to do.

This simple algorithm, in practice, allows patches on the same set of files to be merged successfully in more than 99 percent of the cases without human intervention. This is great for productive collaboration since you can work in a team without locks (and painful serialization) and without loss (your changes are not easily overwritten by others).

Web Patch

And now we want to do that very same thing on the Web: productive collaboration in a team. And we discover that always PUTting complete documents hurts. And also that LOCKing resources only gets in the way (who has the lock token? Uh, Bob maybe. When is he back from vacation?).

Optimistic locking (Etags) is a good failsafe against overwriting other peoples changes. But when you have detected that, can you rescue your edits? Alas, most likely not. So you have the choice between doing all edits again or overwriting the other persons changes anyway. Urgs.

While changes to documents in JSON format might actually work with the UNIX diff/patch, protocols like APP and Web3S serialize in XML. So, a standardized XML diff format would be super useful here. Well, Microsoft itself published such tools in 2002 (no longer working under Vista, I heard), IBM has something similar as well. The diffxml project seems to be in alpha release since April 2005. Hmm.

Giving the world a standardized XML diff format requires some supernatural powers:

1. You need someone with big cred like Tim Bray to pull it through. Once there is a working group around it, pressures from all sort of sides will build up.
2. Making a generic, one-for-all solution is very difficult. And maybe too costly to implement for most use cases. So, some well opinionated design decisions up-front are necessary. Repeat point 1.