Burning Chrome

Raindrops from a brainstorm

Every now and then, I have a really good idea, something that I think would shake up the authoring/editing community and add simple, useful capabilities we've never seen before. Basically, I run into a problem when I'm working on code, and I come up with a solution... but I just don't have the time to prototype it, implement it, and see how it works out. I figured today that I might as well throw a few of these ideas out for the community to chew on.

UPDATE: I forgot to mention - if anyone wants to implement these ideas, go right ahead. :-) I'm posting them because I don't have time to do them myself right now.

I'd like to see what the Mozilla community - and the authoring / editing tools community at large - think. The ideas I'm sharing now are in the extended entry.

Interpreted files through a preprocessor

Problem: When working on chrome files or component files, often the object directory file is an exact copy of a source file. In cases like this, the operating system can create a symbolic link, or "symlink", between the two. However, for files that go through a preprocessor, where other files can be included, or sections of the source file dropped, it's not an option. Despite this, the source file and the object file aren't that different. Sections of one match up with sections in the other.

More specifically, when I get a stack trace from a JavaScript file that's been preprocessed, the JS source lines rarely line up to the object source line numbers.

Solution: Create an annotation (either in the files or outside them) which links sections of source files to corresponding sections of object files. I call this concept a "sub-symlink". (I don't know if anyone else has come up with the idea.) A smart editing program can read these sub-symlinks, and when you edit a section of code in the source file, it can update the corresponding section in the object file. Even better, if I want to edit the object directory file (which for XUL, JavaScript, CSS, etc., don't need to be compiled), then the changes can reflect in the source directory file right away, and I don't have to call make on the object directory again. The smart editor becomes responsible for propagating the change, including to multiple object directories based on a single source directory if the user so desires.

Experimental change sets

Problem: Whenever I go into debugging mode, trying to fix an error, I'll try a bunch of different things. Usually, three or four different approaches don't work. Unfortunately for me, I tend to forget when I've tried an approach - so I end up trying it again thirty minutes later. On the other hand, I'll also tend to forget what changes I've made, so if I end up taking a path that can't work, I want to go back to a set of changes which are better than the original state of affairs.

Solution: Use a revision control system instead of the ordinary file system for storing changes - and when saving a file, export from the VCS to the file system. By this, I don't mean "check changes into the remote repository and see if they work" - rather "check changes into a local repository, which has its own version tracking separate from the remote repository. Then see if the local changes work."

This also has the benefit of permitting comments for each change set, so that I can annotate what I'm trying to do. You could also store all kinds of metadata (including annotations for sub-symlinks!) in the repository. Additionally, undo/redo takes on a whole new meaning - tree-based instead of linear. Just creating the user-interface for that should be interesting.

Subversion could work for this (especially if the editor has access to svnadmin and is very careful about how it interacts with Subversion). However, a distributed revision control system such as Mercurial would work even better, since you have a local copy of the full repository already, and full rights to commit to your local repository without affecting the primary one.

(I didn't understand this at all - what a distributed RCS does better than a centralized RCS, until I read this sentence from the unofficial Mercurial book: "What distributed tools do with respect to forking is they make forking the only way to develop a project." To track a series of change sets while keeping those change sets from reaching the central repository, you essentially have to create a forked copy of the repository - even if it only lives for a few hours. So, a local repository can hold unstable, not-ready-for-bug-attachment changes - and the editor can interact with the local repository.)

The downside is that your project then becomes beholden to the license of the revision control system. This can present real problems, when you want other neat capabilities from open-source projects with incompatible licenses. This is one of those cases where the LGPL is more useful than the GPL...

Distributed editing and reviewing

Problem: For all the strengths Bugzilla has, it's really hard to make a change to a patch. What happens is the reviewer says "Do this instead of what you're doing here. r+ with that change." Then the original patch author makes the change locally, submits a new patch to Bugzilla, and checks it in.

Solution: Review approvals are really about agreeing to sections of a patch, and more specifically about disagreeing to sections of a patch, suggesting improvements. (I am ignoring r- issues for "this patch is not even close to being ready".) Here, distributed RCS's may offer us a new working model:

1. Alice makes changes A, B, and C to a file.
2. Alice then submits it to Bugzilla as an attachment.
3. Bugzilla makes a copy of the central repository for that bug and applies the patch. If the patch doesn't apply cleanly, Bugzilla rejects the patch and tells Alice.
4. A week later, Bob tells Bugzilla "I want to review this patch." Bugzilla updates the bug's repository from the central repository and finds a conflict. Bugzilla says to Bob, "Sorry, there's a conflict, don't waste your time." Bugzilla then e-mails Alice, "Hey, your patch has bit-rotted. Clean it up, please." Alice works with the bug's repository (possibly her own first) to resolve the conflict.
5. Bob, reviewing the patch, doesn't like a few lines of change B. He knows what he wants, though, and modifies change B in the Bugzilla repository for that bug. We'll call this change B₁.The remaining sections he marks as r+.
6. Alice sees B₁ applied to the bug's repository and agrees that's better. Alice then marks r+ on B₁. Bugzilla reminds Alice the patch has r+ for all sections. Alice then requests super-review.
7. Catherine, doing super-review, objects to a part of change C, and submits an alternative, C₁, to the bug's repository. She marks A and B₁ as sr+.
8. Alice disagrees with Catherine's change, and amends it again, offering C₂.
9. Catherine likes it and marks C₂ as sr+. Bugzilla tells Catherine that the patch has r+ and sr+ for all sections directly, and e-mails a notice to Alice.
10. Alice checks it into the central repository.
11. The Firefox tinderbox goes orange. :-) Alice fixes the bustage, posts a note to the bug, and everyone's happy.

It's a few more steps, and Bugzilla has to do a bit more work (needing a bigger hard drive), but it allows for interactive editing of a patch. Less work on the part of Alice, and Bob's and Catherine's suggested changes go right in.

Posted by WeirdAl at July 14, 2007 5:37 PM