FF modularity discussion and Thunderbird backend
ishikawa at yk.rim.or.jp
Thu Oct 13 22:33:02 UTC 2016
On 2016/10/14 4:04, Mark Rousell wrote:
>> 4) a website. This is partly intended to be a demo of how Thunderbird
>> could be deployed in a similar manner.
> I've been involved in a project (unrelated to Thunderbird) that is
> intended to work in this manner, i.e. be able to work on
> desktops/laptops and as a web application, complete with extensions that
> don't care if they are running locally on the desktop or in a browser.
> From what I understand of Thunderbird, it's surely a long, long way from
> being able to do that. Many of the same problems that are facing Firefox
> face Thunderbird in this context, such as (a) Thunderbird's UI is not
> encoded in HTML and (b) and moving to HTML (as well as all the other
> changes needed at the same time) will break extensions. And backward
> extension compatibility really, really matters for Thunderbird (and
> Firefox in my opinion).
I would like to mention only that
the choice of programming plays an important role for the success
of a program [in terms of long-term maintenance and ease of modification
to grow as it meets the new needs of user community]
but it is not a panacea.
The position or the attitude of the programming/developer community
also is very important.
Here I would like to point out one issue, that has been like a thorn to me.
- firefox, the browser, did not have to handle large explicit writing
of user data locally on a file system,
except for the implicit user preferences (or writing HTML save data
in sequential manner), etc.
[This has changed somewhat since FireFox OS, and HTML5 now allowing
user-controlled writing to local store.]
So despite its handling of network-level I/O errors is excellent,
attention to local file system I/O error issues in mozilla code base
has been dismal.
You can find code that does not pay attention file I/O errors very
- OTOH, TB in its nature, had to deal with large amount of random file
I/O for local mail storage and quite complex backend R/W db
(not many of us feel comfortable to keep our
private messages online on somebody's data storage forever: that is
the reason for the necessity of such I/O. Unless everybody becomes
happy to keep their mails on google, amazon, or MS servers, this
TB's had to cope with very complex I/O operation.
For example, in the imap case, we had to sync the local operation
with the remote operation. (And it seems that there are many bugs in
As far as file system I/O goes, I think C-C TB is three times as
complex as FF. I am afraid that the majority of mozilla developer
community seems to miss this point.
I mentioned above becuase I have noticed the lack of proper file I/O
error checking from the viewpoint of C-C TB code. I suspect this
resulted from the relatively light emphasis placed on file system write
due to the main project (browser) not paying enough attention to file
system errors until lately [that is my take on the situation.]
A case in point regarding I/O bug: during V2 to V3 transition time, I
was horrified to see the low-level code ignoring the error return of
system calls - this had resulted in my loss of half a mail folder when
compacting failed due to overflowing file system. Since the bug was not
fixed quickly enough,I was forced to check the source code myself and
was appalled at the code quality. But I did not like the buggy MS mailer
on Windows, and I liked the cross-platform availability of TB and so
decided to fix the problems and continue using TB.
The attitude toward file I/O operation errors in the whole mozilla
developer community does not seem to change
overnight [yes, there are, and have been people concerned about I/O
error issues, but we have still many files where low-level I/O return
codes are silently ignored.].
Any help from programming languages to make programming fast and
"correct" or "reliable" would be a long way to make the maintenance of
C-C TB code easier.
So although there is an issue of inherent developer community's attitude
with regard to emphasis placed on code quality issues (and this will
make or break a project unfortunately in the long run no matter what
programming language is chosen), I am all for programming language with
This is an improvement for a large programming project.
Type-free script language is OK, maybe for 500 lines of code that is
going to be thrown away soon, but not for something like C-C TB or M-C FF.
(I have coded programs in bash shell, perl, awk, ruby, TCL-express
combination, variety of lisps, C, a few variety of Pascal-like languages,
and I can say confidently that typing is a necessity to keep sanity in a
large project with many programmers who come and go.
I am not going to say we should rewrite C-C TB in a strongly typed
language such as Haskel although if someone has come up with such a
port, that would be nice :-)
Come to think of it, my fist C-C patch was about a value that was
assigned to a variable not expecting such a type and complained in a
loop. When I casually proposed a seemingly simple patch, I was told that
it was not right, and *THE DOCUMENTATION STATED* the value ought to be
this type: JS could not enforce such specification, of course, and I was
dumbfounded to find that people HAD TO COPE WITH THIS MANUALLY while
computers with proper programming languages can free them from such
mundane automated tasks. As I say, a short [200-500 lines throw-away
script that will probably be used for 3-6 months or even longer if not
to be modified], can be written in a language without strong typing, but
something that is used by a million users over the course of more than
a decade ought to be done in a more reliable language WITH GOOD DEBUGGER
SUPPORT (this is another thorn I noticed. C++ and JS combination via
XPCOM is not friendly to good debugger support, but I digress.)
My understanding is that some typed JS extension basically genertes a
better JS (with proper run-time check, etc.) by statically analyzing the
code. If we can find the way to use it INSIDE C-C TB, I am all for it.
Just my 2 cents worth.
More information about the tb-planning