Moving Thunderbird towards libxul

Ben Bucksch ben.bucksch at
Fri Jul 16 18:41:34 UTC 2010

  On 16.07.2010 14:54, Robert Kaiser wrote:
> Ben Bucksch schrieb:
>>> Option 1 - Mailnews, mail as separate libraries
>>> Linking with the external API means we loose a lot of the string
>>> optimisations that we get from the internal API. e.g. nsAutoCString
>>> equates to nsCString in the external API, and so you won't get
>>> pre-allocated memory on the stack.
>> The strings API is the main pain point when it comes to libxul, not just
>> for Thunderbird.
>> Can we change the libxul API/ABI to include a sane string API that does
>> not lose performance and is comfortable to use?
> I doubt we can significantly change what libxul exports - that would 
> need to be a platform change, and someone would first need to submit a 
> patch there and get reviews. Nothing is impossible, but that would 
> need to be done.

Obviously. I think this change for Thunderbird is big enough (with 
enough work and later implications) to warrant this on TB and XULRunner 

Also, I think it would be a good platform change and XULRunner /should/ 
be perceptive, because the string API is *the* major problem for other 
libxul users, too. At least it's the main reason why I avoided libxul in 
my projects.

>>> Option 2 - Mailnews, mail included in libxul
>> It seems to me that Option 2 is not really libxul, but rather
>> libthunderbird, and quite counter to the idea of libxul.
> Well, it's the same way Firefox appears to be going right now, so it's 
> not counter what is going on there, and IMHO it's not counter to the 
> idea of libxul - but it's counter to the idea of XULRunner and to 
> libxul being a strict subset of XULRunner, you're right about that.

Well, if each libxul has different contents, it's not really "libxul" 
anymore. It's "libthunderbird" and "libfirefox", as I said.

Also, I don't think Linux distros will appreciate it, they generally 
assume same libname == same content (and I think anybody does, that's 
the whole concept of names), and need to jump special hoops where this 
is violated. Also, e.g. Ubuntu (and others) ships Firefox and 
Thunderbird based on a common xulrunner package, if I saw it right. I 
guess option 2 would make this harder, while option 1 would make it even 
easier. Your other post says that means we need to support both options. 
Wouldn't it be better to just improve option 1?

More information about the tb-planning mailing list