In Chicago earlier this week, a lot of our discussions focused on
changes to the editor interface.
In the beginning, the editor interface was meant to be a generic way
of making a tree-change to a filesystem; it was the abstract,
procedural incarnation of the XML DTD for tree-deltas.
The main advantage of this interface was the abstraction; in
particular, the theory was that any program designed to "drive" an
editor could be matched with *any* editor implementation.
Additionally, editors can be "composed" together in a chain, like a
Unix pipeline. I (Ben) refer to this as the "plug n' play"
functionality of editors. It already works; I've been able to swap
editors at will (for debugging tests) and the `svn commit' and `svn
update' commands are printing out status letters *because* of
composed editors in action.
As we get deeper into Subversion coding, however, we're finding that
we constantly need to tweak this interface to accomplish our goals.
Needless to say, the changes proposed remove a lot of the editor's
Elegance. Seemingly.
There are two takes on this:
One take (preferred by jimb) is to say, "these changes are fine,
but at some point we should stop kidding ourselves and just give up
on the editor's Generality. If we lose the Generality, let's just
write new asymmetric interfaces that do what we really want."
Another take (preferred by gstein) is to say, "the editor isn't
dead yet; in fact, we're just evolving it to perfection. The first
draft wasn't quite right, and now we're gradually changing it to
what it should have been in the first place."
I suppose the jury is still out on this decision. The changes we're
proposing *seem* to continue to preserve the plug-n-play-ness of the
interface, but only time and testing will tell. :)
Received on Sat Oct 21 14:36:19 2006