Hey Doug,
Douglas Turner wrote on 04.12.2015 06:32:
Lots of questions; let me try. Keep in mind that there are plenty of
points of views at Mozilla. These are my opinions which are influenced by
the gecko developers I work with and the Firefox teams that I support.
Some of this will feel like tit for tat, my intent is only to address each
of your questions.
Thank you for your kind attitude. It's help for a battered soul.
I want people to be able to build products like Thunderbird and BlueGriffon
directly on the web. This is where we're heading.
Do you mean Web technologies, or really websites?
If you mean Web technologies, yeah, why not. In fact, I'm currently
concretely trying to help with that, but I have nothing to show yet.
Typically, web means websites, and that's not always progress.
Thunderbird users use Thunderbird specifically because it's a desktop
application under their own control, not run by a third party. I've
personally been supporting the German Ministry of State including the
embassies. This is highly security sensitive, and they must have
absolute control over their data. The same is true for individual users
with privacy concerns. Thunderbird has a large userbase with this sort
of needs.
The same is true for many other applications.
b. Thunderbird will still need to embed a browser, even if it does not
use any more XUL or XPCOM in the future. Embeddability of Gecko has
always been a poor parent of the project.
Very familiar with that problem... Fifteen years ago I was embedding Gecko
into the AOL/Gateway Crusoe!
Doug! I actually remember that. You were a true hero for me. I remember
being amazed and in awe how you massaged Gecko to be embeddable, all by
yourself, a lonely quest. It wasn't easy back then, your first had to
dis-entangle the browser APIs. If I remember correctly, nsIWebShell (and
good parts of nsIDocShell?) are your brain children.
Every time I think of Gecko's embedding story, I get sad when thinking
of all the efforts you put in there, and how little care was taken later
to keep the APIs stable, which is crucial for embedding. And how much
mind-share we lost because of that. Gecko could have been the fabric for
many products, the computing world. (And is, more below)
Will it change or should Thunderbird look for rendering engine alternatives?
This is something the TB team should figure out -- I am in no position to
talk for them.
I don't think you were intentionally avoiding the question, but Daniel
was asking whether this is going to *change*, whether the embedding
story will get tangibly better from Gecko's side, not from Thunderbird's.
c. if a is true, then a very long list of third-party apps, like my own
(BlueGriffon line) or Seamonkey, will be very deeply impacted. What
about them/us?
This is speculation. Maybe someone would carry a branch with XUL support.
Or maybe someone would build a transcompiler. Or maybe the authors of these
programs would rewrite to the web.
This is my cue, why I post here.
As a Mozilla consultant, it is my day job to support companies that use
Mozilla technology in their own software products. You don't see them,
but there are lots. You have the whole range from Firefox extensions
written to support their own business, all the way to products using
Gecko to inspect webpages to make automated security audits of websites,
and in some cases even entire applications based on Mozilla, like
Thunderbird.
In some cases, the company's flagship product is based on Mozilla
technology, and it's so engrained that removing XPCOM and XUL would mean
simply a complete rewrite of the whole product. Just the attempts in
recent years to "clean up" XPCOM has caused them *major* pain (and that
pain was sometimes the very reason why I was hired, because they were
hopeless), again and again. Many of them have actually given up on
Mozilla already, because it was so much pain. Some are so deeply rooted
in Mozilla that they don't have much of an option.
Killing XPCOM and XUL will simply kill their product. Flat and simple.
Thunderbird is not the only one. You probably have no idea how many
there are. You get an idea when you look at AMO. There's more happening
outside AMO, because it's internal or proprietary.
Keep in mind, there is no plan to remove XUL or stop supporting XUL.
Firefox depends on XUL and it's unlikely that will change anytime soon.
Doug, you can't believe how relieved I am to hear that. That's what I
had always understood.
HTML5 is the future, we'll slowly migrate to there. I hope that Servo
will be our renderer in the not too distant future, and I'd be happy to
see XBL eventually die. Some change is necessary, the question is how
the change happens. First have a replacement that's better and more
powerful, then let it pick up, see how people like it, wait a few years,
then kill the old tech.
Now I hear 18 months until death of XUL extensions, which would
effectively eradicate the majority of AMO and internal projects, and
that's an entirely different story. This is the point where projects are
at immediate risk, projects get canned. Very concretely, one employee of
mine resigned.
I would like to have *more* of this kind of discussion out in the open,
and most importantly to have this open discussion determine the decision
that's made.
All in all, thank you, Doug. Your post was speaking reasonableness.
Ben
_______________________________________________
governance mailing list
[email protected]
https://lists.mozilla.org/listinfo/governance
