After spending some time developing ReoPath (or RPath), a XPath-like language for RDF, I've recently switched into testing mode. At first, I just wanted to test the code for memory leaks, but then I realized it might useful to prepare a set of test cases I could run through. Eventually, I could run through all of the test cases automatically in order to test for regressions, memory leaks, and other things.

So in the process of testing, I made a table of all of the test expressions I ran. I ended up with 330 test cases. Since they only test features I've implemented already, I expect that number to grow ever higher over time.

I managed to fix numerous bugs, so the process was quite useful. I also discovered that ReoPath as currently implemented contains a Bizarre List Handling Rule of Evil, that can cause some unexpected results. The problem lies in that I used the same style of syntax for two purposes. I'm not sure if I should remove the feature or not. On one hand, I spent quite a bit of time implementing it and fixing bugs in it, yet in the end it seems to be more confusing than it's worth.

Number of messages containing spam or viruses received in the last 24 hours: 0

Number of messages received discussing spam or viruses from the mozdev mailing lists in the last 24 hours: 19

I'm not complaining though. I suppose I'm lucky I needed to get a new email address -- it means that I don't appear in anybody's address book. Also, the people I know that would have my email address are all Mac or Linux people.

I haven't posted much lately. One reason was that I went on a sudden vacation to my parents' new house for a few days.

The other reason is that I have been busy working on significant changes to the template building code for Topicalla. Before, it used to crawl the DOM looking for template related tags and attributes every time a change was made. While it isn't particularly a performance problem at the moment, it would be too slow and tedious for more complicated cases.

Now, instead, it builds up a list of dependencies so that when something changes, it only needs to recompute those nodes in the DOM which would have changed as a result. For example, if template expressions only exist on a <tree> and some <treecell> nested lower down, the builder only looks at those nodes. It also handles changes to the underlying RDF and should be able to ensure that even complex expressions are only recomputed when necessary.

There's still a few things to clean up and a few regressions have occured, but I hope to have those fixed soon. With a bit more work, it should be enough to handle everything that XUL templates can handle, except of course, a lot more -- for example, working in X/HTML.

Some notes about Phoenix/Firebird
I wrote this back when Phoenix/Firebird was first getting started. I'm just posting it here to remind me to ensure it's up to date. And because I realized it isn't linked from anywhere.

The difference between communicating in person and communicating online is that in person you can almost always tell whether someone is trying to insult you or not, whereas online you can't tell, so if there is any doubt, everyone just assumes that they are.

I've added some date handling functions to Topicalla. So now, I can view a set of weblogs in a timeline view. It shows when postings were made. There's a bit of overlap as the entries were made fairly close together. Eventually, you'll be able to zoom in to see each entry better.

A number of people have been coming to XulPlanet after being referred by someone who suggested they investigate XUL to see if it is suitable for their purposes. They have wondered why there is no introductory text as to what XUL is and why one might want to use it. So I added a Why use XUL? page.

I posted this on Mozillazine. I thought I'd repost it here because I found it interesting:

Over the last few years, I've seen many people talk about how there isn't a good killer feature in Mozilla. Or in Opera. Or Linux. Or in any other product one might mention. Marc Andressen recently thought so too. Why? Because killer features don't exist. You can't create them.

One could say that tabbed browsing, or popup blocking or any of the Firebird extensions, or 'tools to organize and information-overflown workflow need' (this quote from the post I was repying to) are killer features. Are they? They could be. But they really aren't. Even though I use Mozilla because of them and wouldn't use a different browser.

You see, when a new kind of product is created (the very first browser, the first spreadsheet, the first music downloader,... ), nobody knows much about it. So the creator adds feature after feature. By the time 3.0 or 4.0 comes out, people pretty much know what the application is all about. 'Killer apps' will have millions of users by then. At this point, all of those users have a hard-wired notion of what that kind of application does. For a browser, for example, it views web pages, has a back and forward button and you can use bookmarks. Any feature you add beyond the 3.0/4.0 release simply gets ignored. The users don't care any more about features.

Microsoft keeps coming out with new versions of Office. Every version has lots of features, but no one notices them. Some people yell 'Bloat!", and complain. People figured out what a word processor was supposed to do 10 years ago. Features added after people decided on what the hard-wired definition of word processor was simply go unnoticed, regardless of how useful they might be.

People won't switch to Mozilla or Firebird because of any great features, because those features aren't what people think of as a browser. The only way to get people to use a browser is if that browser is something else. Like, a complex information-overflown workflow organizer.

Oh, and to anyone who wants to create that, don't put a Back button in it -- people will think it's a browser.