2015-06-16 1:36 GMT+02:00 Jean-Christophe Deschamps :
> While I can agree with some of the most obvious "don't be dumb" remarks,
> there are many things that can't be let unchallenged. And I don't
> appreciate the overall tone: "WE at MozillaBigBalls are all clever enough
> to use SQLite smartly but you mere mortals are not, so don't even think to
> use that fragile piece of softawre."
>
There's never been that kind of tone, the article has been written to point
new Mozilla codebase contributors at possible pitfalls we already hit in
the past, and actually help them making informed decisions.
It's not intended for global consumption. Sure it's public, cause there's
no reason to "hide" technical document that might be useful to
contributors, just to complicate their access. Can you find any page that
states Mozilla doesn't like SQLite or wants anyone to abandon it? It is
used everywhere, from mercurial repositories to Firefox OS...
> In it's introduction, the blurb talks about SQLite hidden complexity. Then
> it avdises Mozilla pluggin developers to avoid SQLite at almost any rate,
> due to "performance reasons", and recommends compressed JSON/logs instead.
>
It actually briefly explains in which cases a JSON log can work better and
at the end it also states what to do and avoid if still SQLite is found to
be the best store (and it clearly happens!). It tries to make people think
before doing.
> Yet this guy(s) advocate that *-every-* pluggin devs should independently
> roll his own storage layer
It states to evaluate alternatives. Existing alternatives like OS.File
writeAtomic and JSON. Those are already used with success in both the
products and add-ons, when it makes sense. Sure the developer mus think to
durability, backups, coherence, but would it not be the same if he'd use
SQLite? You must find the right compromise between durability and
performance, you still have to handle corruption cases. Thinking about that
stuff is part of normal planning for any feature, independently from the
chosen store.
> Then another question remains: instead of putting the onus on SQLite being
> huge (footprint) and slow (CPU, the 22s "example"), why don't the author(s)
> of the blurb question the real root causes of the evil they condemn and
> openly recognize that the problem lies entirely elsewhere, perhaps in
> Mozilla core code design itself?
>
Because it's clear the article is about SQLite use in the Mozilla codebase.
It's clear there are issues in the Mozilla codebase itself (I'd be
surprised of the opposite!).
> After all, it's Mozilla devs themselves who designed pluggin APIs and let
> "spurious main-thread SQL statements" be possible. If they were sooo
> clever, they would never had allowed that and they also would have wrapped
> SQLite interface in a strictly limited set of rules enforced by a safe API.
> That, they won't tell you.
>
And they'd have a 100% bug free product with millions lines of code... No,
that's unrealistic. The Mozilla codebase comes from the 90s Netscape
codebase, at that time the most common thing was a single-threaded and
single-process browser, able to show text, some images and tables. The
reality evolved A LOT and the code had to evolve to cope with it. At the
time mozStorage (the SQLite wrapper) was written, there was still that kind
of vision, and it was written as a main-thread synchronous API. Sure, now
we all know it was wrong, but at that time it was the right-ish thing to
do. The API grew a purely asynchronous alternative, but when you have
hundreds millions of users and thousands of add-ons using an API, you can't
just say "sorry, we now break you all". You must play fairly.
Sure, the Firefox add-ons are the most powerful add-ons around, they can do
anything, and while this might be (as you point out) a downside, cause they
can perform poorly, it is also their major selling point. There are still a
lots of things you can do with a Firefox add-on that you can't do in any
other browser add-on.
Also, this has nothing to do with the fact SQLite can still be the wrong
choice for certain data store needs (as it's the best for others), that is
still the main purpose of that article.
> Also, if Mozilla devs were sooo much more clever than average Joe and sooo
> caring about performance, they certainly would have fixed the hundreds of
> memory leaks that plague FF users
>
This is going off topic, I'd be happy to digress about this but it's not
the right place. If you have suggestions or bugs, the codebase is open and
the bug tracker is public, you can reach every single developer through
mail or IRC. You have all the tools to make the difference.
Marco
