FF modularity discussion and Thunderbird backend

ISHIKAWA,chiaki 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
    won't change.).
    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
    this area.)
    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 mailing list