“One thing that I’ve come to think in recent months is that to convince extension authors to use a feature, you need to have a usable prototype extension.” Preaching to the choir here (JunQuilla and FiltaQuilla are really demonstrations of core features). But there are serious obstacles to that in practice. Two issues: first, I’ve argued unsuccessfully that core developers should actually package new features as extensions when possible, both as a trial period for the feature and as a way to make sure that they eat the dog food of using extensions as a way to add features. But I’ve not gotten any traction with that. Second, and this is fairly subtle, I think that the world is divided into “core developers” and “extension writers” in many people’s minds – with “extension writers” a different, probably lower, class of people. Put too much effort into extensions and you move into that lower class.

“I think that if a comprehensive tutorial on making new account types were presented … ” As I said in my post, it is hard to get motivated to do that when there is no agreed on direction for the future of the core code. It would be very easy to document in detail features that are only valid for 3.2a1pre. I’ve never figured out how to get any agreement on roadmaps for the future in mailnews development areas that multiple people are likely to have opinions on.

It would also allow an extension such as WebMail to not run its own server, since the account just request over HTTP protocols and be parsed right away, instead of converting an HTTP protocol to POP3.

Another example is OpenChange which has some documentation about creating a MAPI protocol as an extension for Tb: http://wiki.openchange.org/index.php/Thunderbird_Plugin and http://wiki.openchange.org/index.php/SoC/Ideas#Thunderbird_Integration (among other places).

I don’t know if there is other active interest for other accounts, but I’m confident people would make other ones if it was easy enough. There’s a few (mostly unused) protocols Tb doesn’t implement, but other examples besides that? Perhaps Facebook messages (or other sites that have custom messaging system), web forums (per jcranmer’s example extension), Google Wave, maybe integration of VoIP in some way and I’m sure there are others; as well as things that don’t necessarily come in a “message format” but could be forced into one (comments on a Wiki talk page, etc.)

Making new account types, as I’ve argued in the past, is one of the things that should be easy to do in Thunderbird. It’s not really true that no one has tried it before: the Webmail extension does try to add new account types in TB (via implementing its own POP/IMAP servers!). I think the lack of extensions is symptomatic of the sheer difficulty of making a new account type–in order to get it to work, you either need to reimplement large portions of core code or you need to distribute binary components. Not to mention all the grief the core code gives you in trying to circumvent the closed system.

One thing that I’ve come to think in recent months is that to convince extension authors to use a feature, you need to have a usable prototype extension. The folder pane was designed to be extensible, but as I recently discovered, it was broken: no one noticed it because no one tried to make an extension!

In short, I think that if a comprehensive tutorial on making new account types were presented to potential extension authors, enough to make it relatively easy to do the common backend tasks, the uptake would eventually come. Even if this is not true, we would have a wonderfully documented subset of code.

As I understand it, one of the motivations for changes to the folder tree (including such things as removing the ability to show folder size and message count in another column) was to improve its ability to handle a wide variety of potential types of items. But so far that has not happened. I don’t really know if that is just because it is difficult to easily do (as my post and jcranmer’s series shows) or if the demand just does not exist.