I read Ben Goodger’s note about losing an inbox with vague interest a few days ago. Then it happened to me, almost exactly the same way it happened to him:

I routinely get upwards of twenty thousand virus mails, junk mails, undeliverable-return-to-sender return envelopes for messages I did not send, and other crap mail per week. A large portion of these should be caught by my ISP virus filter, but oops! Covad doesn’t have an email virus filter. I have six manual filters that catch about 80% of the mail and delete it automatically, and about another 15% is caught by the Mozilla mailnews junk mail filter. That leaves about one thousand junk mails per week that I have to delete manually. What I didn’t notice is that the junk mail and auto-deletion filters don’t cause compaction of the inbox mbox file. Over Thanksgiving weekend, I left my mailnews client running in a VNC server, but I didn’t shut it down or tend it at all. During this time period the mbox file for my Inbox, Junk Mail, and Trash folders all went above 2G. Apparently this causes mailnews to go crazy and die. It tried automatically rebuilding the MSF file for my Inbox several times, and then keeled over and deleted the entire Inbox.

So, I have a couple questions for mailnews cognoscenti:

1. Can manual filters really delete mail so that they’re not even in my Trash?
2. Can the junk mail filter delete mail, instead of moving it to Junk Mail?
3. Can mailnews automatically detect that a folder is really large and compact it before it hits 2G?
4. Or at least stop retrieving new mail when it gets close to 2G?
5. Are there other “workaround” automated ways to avoid dying when I’m away from my email for a few days?

In order to make the mozilla build process less painful for beginners and support additional work to make the build more modular, I will be landing bug 261232 very soon after the tree opens. This bug will require all builders to specify two flags in their mozconfig file:

ac_add_options --enable-application=foo

Available options are as follows:

• suite (Seamonkey)
• browser (Firefox)
• mail (Thunderbird)
• composer (standalone composer/NVU)
• calendar (Sunbird)
• xulrunner
• standalone (used for various build options like standalone xpcom and xpconnect)

a flag for client.mk to specify what sources to checkout

mk_add_options MOZ_CO_PROJECT=foo,foo2,foo3 (same options as above, except “standalone” is unnecessary).

This will require everyone to update their standard .mozconfig file, and require updating most/all of the tinderboxen.

In addition, the following variables will change:

MOZ_INTERNAL_LIBART_LGPL will be obsolete; use
mk_add_options MOZ_CO_MODULE=mozilla/other-licenses/libart_lgpl

MOZ_MAPINFO will be obsolete; use
mk_add_options MOZ_CO_MODULE=mozilla/tools/codesighs instead

I will coordinate with Chase and other members of the Foundation staff to make sure that the core tinderbox build machines are configured properly.

Please reply and discuss on the newsgroup netscape.public.mozilla.builds.

I have written a document about incremental steps moving toward libxul. Please read it if you are interested in Mozilla’s build systems or code architecture.

This is a call for volunteers to smoketest the localized releases of Firefox RC1:

We have produced the localized builds that we want to become the RC1 localized releases. They are available at http://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/latest-0.11-l10n/

In order to certify that these builds are usable and ready for RC1 release, we would like each build to be smoketested. This basically means that a human has to download and run the build, and certify that the build basically works as intended.

Volunteers are asked to download any builds that they are able, test them, and report the results on the smoketest wiki page: http://server.lynggaard.org/l10nWiki/Wiki.jsp?page=SmokeTest

Since many localization teams do not have access to a mac, anyone with a mac and time to do testing would be greatly appreciated.

Please try to test the following items in particular:

The installer custom install options (if you are testing an installer build)
The help system (some builds have only English help, that’s OK as long as it works!)
The Options/Preferences dialog

We hope to “bless” these builds as RC1 tomorrow, unless serious errors are found. (Yes, we know that the linux builds don’t have working talkback. No, we don’t know why.)

When preparing for the localized releases of Firefox RC1, we discovered a chrome registration error that might bite extension authors in the behind. Extension authors, please apply this fix to any contents.rdf files which register locales.

NVU is great, and I want it to get even better. So I’m presenting my “NVU wishlist”, organized in no particular order other than what I could remember being annoyed by. I am thinking in terms of what I want as a user, not how hard it would be to implement, so some of these requests are unlikely to make a NVU 1.0 release:

• Smart quotes. I like proper open- and close-quotes, they make a page look professional. And when the quotes are serialized, I want them to use numeric entities instead of “ and ” because that is much more portable than the HTML entities.
• Don’t use “body text”. I don’t ever want to use body text, I always want real paragraphs. Currently (as of .50) using paragraphs is fairly painful, because mysterious body text blocks appear where I don’t want them.
• Have a structured outline mode. Instead of the left-hand ruler, which I don’t ever use, I would like a structured outline displaying my headings and paragraphs. It is not necessary that this allow the headings/paragraphs to collapse, although that might be kinda cool.
• Auto-TOC and auto-index features. I would frequently like to be able to have an index page with links into sub-pages (and sometimes back again). Also, automatic or semi-automatic linking of index and glossary pages; using DHTML to display these glossary items in another popup window would be a cool addon. Note that this is something that might be handled really well by an NVU extension, whenever NVU moves to the toolkit extension-management architecture.
• Upload/save relative-linked documents properly. My FTP server loads the website from ~/httpdocs/, and I make extensive use of site-relative links (link href=”/index-new.css”). These links are not loaded properly in edit mode, because the relative-URI parsing tries to load them from FTP ~/index-new.css which fails miserably. This is really a bug and not a feature request, and glazou and I have already discussed a technical solution, so it may be already happening in the NVU 0.6 series.
• Local/Remote site manager. The left-hand toolbar is nice if you are editing pages directly, but I frequently need to keep a local copy of the website and update it in batches. A Dreamweaver-style local-and-remote site manager would be invaluable to me.

Anonymous access is now available for the localization cvs repository, thanks to the hard work of Mike Shaver and Dave Miller. Thank you! You can now check out and build any Firefox localization with the following procedure:

• cvs -d :pserver:anonymous@cvs-mirror.mozilla.org:/cvsroot co -r AVIARY_1_0_20040515_BRANCH mozilla/client.mk

• Create a file mozilla/.mozconfig with at least the following contents:

  . $topsrcdir/browser/config/mozconfig
  mk_add_options MOZ_CO_LOCALES=ab-CD you can also specify 'all'
  ac_add_options ----enable-ui-locale=ab-CD

• cd mozilla;
make -f client.mk

To look at the available locales and whether they are building correctly, see the temporary tinderbox.

My local machine is running a tinderbox for localizations of Firefox 1.0. You can see the tinderbox page here.

Martin Creutziger has graciously agreed to host the langpacks which are produced by this build here. Note that these langpacks will install on a Firefox PR build, but you won’t be able to use them unless you start Firefox with the command-line argument -ui-locale ab-CD. If you install my locale-switching extension, recent aviary branch nightly builds should “just work”.

I currently do not have the machine set up properly to produce good binaries (it is a RH9 box hacked with updated RPMs from Fedora Core, and a gcc 3.5 trunk compiler with a couple of custom patches). The good folks at the Mozilla Foundation are working feverishly to set up a tinderbox which stages localized builds to the main mozilla.org FTP server.

For the record, getting anonymous access to the l10n CVS tree (and the website tree) is covered by bug 211375. There is a mysterious error message which needs to be debugged.

There has been a lot of griping on the localization groups about the lack of locale-switching UI, but I never saw a working extension for Firefox PR (coupled with the fact that my chrome registry bug means it wouldn’t work anyway). So I whipped one up. Check it out.

RDF has been touted as the data model to model all others; the way to represent all metadata on the web. For those of us who are “architects” at heart, this is an extremely attractive proposition. The problem is that it is destined to fail, for technical and human reasons.

Let us examine the technical issues first. What are the chief advantages claimed by RDF?

• Extensibility: RDF graphs can represent any data concept if there is an appropriate schema, and anyone can create a schema without conflicting with other schemas
• Aggregation: RDF can combine information from multiple sources, to combine and enhance knowledge

The technical problem is that you cannot achieve both of these goals at the same time. Any RDF aggregator must understand the data schemas being used, or the aggregation is worse than useless. For example, imagine two RDF graphs, both containing a sequence:

r:foo rdf:_1 r:obj1
r:foo rdf:_2 r:obj2
r:foo rdf:_3 r:obj3
r:foo rdf:type rdf:Bag

r:foo rdf:_1 r:obj1
r:foo rdf:_2 r:obj4
r:foo rdf:_3 r:obj5
r:foo rdf:type rdf:Bag

The logical aggregation of these graphs is:

r:foo rdf:_1 r:obj1
r:foo rdf:_2 r:obj2
r:foo rdf:_3 r:obj3
r:foo rdf:_4 r:obj4
r:foo rdf:_5 r:obj5
r:foo rdf:type rdf:Bag

However, let us imagine the same graphs, except that r:foo is now a Sequence instead of a Bag:

r:foo rdf:_1 r:obj1
r:foo rdf:_2 r:obj2
r:foo rdf:_3 r:obj3
r:foo rdf:type rdf:Seq

r:foo rdf:_1 r:obj1
r:foo rdf:_2 r:obj4
r:foo rdf:_3 r:obj5
r:foo rdf:type rdf:Seq

The logical aggregation of this graphs keeps a “r:obj1” in the graph twice, because a Sequence is order-sensitive:

r:foo rdf:_1 r:obj1
r:foo rdf:_2 r:obj2
r:foo rdf:_3 r:obj3
r:foo rdf:_4 r:obj1
r:foo rdf:_5 r:obj4
r:foo rdf:_6 r:obj5
r:foo rdf:type rdf:Seq

There are, of course, much more complicated examples, and there is frequently room for multiple interpretations of how to aggregate the same data. The basic point is that given a set of graphs, an automated tool cannot make an intelligent aggregation if them without understanding the schemas involved. This means that RDF is really either extensible or aggregatable, but not both.

Secondly, and much more important, is the human factor involved in metadata. It is a basic fact of life that what is not seen, is not updated. Web authoring tools like NVU know this, and so they prompt you to enter the <title> of a page when saving it. This makes the invisible visible. RDF has no visual representation, by design. It is intended to be processed by automated tools (of unkown type) for an infinite variety of purposes. This means that humans never see the metadata, and will therefore never maintain the metadata.

The obvious solution to this problem is to make the metadata visible. So what we really need, say the RDF aficianados, is a data-browser. This browser will allow you to “surf” the metadata of the web, just like the web browser of yester-year allows you to surf HTML. This is a fine idea, except that nobody has apparently tried to integrate this “metadata browser” with an actual browser. Unless you do that, you are doomed to niche or non-existent adoption, and all the fancy theories in the world are useless.

So what’s the solution? My solution is simple: extend the HTML <link> and <a> tags with additional profiles (a la XFN), so that metadata is attached to visible entities if possible. Define a standard so that RDF can be embedded in the HTML head element, and brainstorm some extensible rendering framework so that browsers can actually display RDF metadata.

This was, I believe, one of the original inspirations of the RDF/Aurora code in Netscape 6, which was quickly swallowed by extreme and bizarre demands that RDF define the UI of the Netscape browser. Since we are now agreed that RDF was generally a mistake as a general-purpose data-binding language, and we are revamping the XUL templates to work with simpler XML/JS/SQL data, we can actually work on a real intertwingular metadata browser tightly integrated and extending the basic functions of the HTML browser that have been so universally successful.