Announcing Start of Listarchive!

Last night, I started work on the first of my triad of extensions detailed in this earlier post, listarchive. So I can't come up with a good name. The most up-to-date information will be available at this web page, but I will summarize some key points here.

listarchive is an extension that first and foremost aims to provide sane access to mailing list archives as if they were a simple folder in Thunderbird (and probably Seamonkey as well). From a certain user request, it is likely I will touch on other aspects of mailing lists as well in this extension, e.g., the desired "Reply to List" feature. In addition, however, I will also be using my experience with developing this extension to write a guide to developing extensions involving more complex operations in Thunderbird.

The extension, however, is still very much in the design phases. I would very much welcome any feedback to be sent to Pidgeot18+listarchive@gmail.com (with the "+listarchive" component, it helps me triage replies). Specific pieces of information I am looking for at this point:

• Mailing list archive URIs; I ask in advance to not send any more mailman URIs (unless it happens to be in a different language than English), as I have several already. I am most interested in accumulating a diverse supply of mailing list implementations and international versions to best determine what impact internationalization plays on list archives.
• Ways in which you think a mailing list archive should tie into regular email. For example, I believe it should translate a mailing list URI reference (e.g., http://lists.whatwg.org/pipermail/whatwg-whatwg.org/2008-May/014646.html) into a link to open the message up as a TB email message.
• Any questions or suggestions for UI (this comes more into play once I have some prototypes working).
• Any other question you may have (related to listarchive). I'm quite willing to answer them.

Thanks in advance for any comments you send me. I'm also hoping that this will work out well (no reason it shouldn't).

The Web in an email client

It is an unfortunate accident in the history of the web that one protocol has been given precedence among all others. I am referring to HTTP, of course, which is the main source of access from the web at large. In specific, there are three things which are accessed from the web which should not be:

• Web forums
• Webmail
• Mailing list archives

Why is it so bad? Because it's abusing HTTP and HTML. Take web forums: the NNTP protocol is much better at organizing the information than HTTP is. It's also a case where the user is sending a lot of information to the server, which requires a better connection than heavy use of HTTP POST. But they're not accessible from NNTP, which is a shame. I would much rather read it in a client that makes handling the updates easier (noting which posts of which threads are new, etc.) than using phpBB or example. The current system requires some annoying combination of RSS feeds or email notification what news clients do natively.

The solution to this problem is simple: give an email client the ability to act as a front-end for this system. Simple being relative, there are some problems that have to be resolved. The first is lack of strong standards in the area. Sure, phpBB is one of the most common systems. But that's not a standard. At some point, it's going to be like how TB handles spam message header recognition: give it a definition file somewhere. I'm thinking XPath should be able to do the trick.

The second problem highlights the limitation of the system. There is no procedure for designating context of threads (or a poor one, if it exists: cf. W3C's mail archives). At some point, the web scraping would have to do some educated guessing about stitching threads together. That would be killer, but immensely difficult.

In terms of TB, I would like to start working on one component soonish. I am guessing that it would reside in mailnews/extensions/webscraper/, and rely on XSLT's XPath implementation. First, I would likely use my moderate python knowledge to scrap out information and then port that into a C++ or JS component in mozilla codebase. However, all awaits jminta's kill-RDF to go through: webscraper would probably support three (!) new account types, with some folder hairiness to go along (many forums provide user listings that could be a pseudo-addrbook folder).