What happened to hiring an architect?
axel.grude at gmail.com
Fri Dec 16 16:30:03 UTC 2016
Just some answers from my perspective as a (mostly Thunderbird) XUL Addons developer
> *Subject:*Re: What happened to hiring an architect?
> *From:*Disaster Master <disasterlistmanager at gmail.com>
> *Sent: *Friday, 16/12/2016 13:57:04 13:57 GMT ST +0000 [Week 50]
> On 12/15/2016 5:00 PM, aleth at instantbird.org <aleth at instantbird.org> wrote:
>> I'm not aware of any timetable for removing XUL/XBL from m-c.
> Ok, clarification on this situation is sorely needed...
> First - a quick google reveals that XBL is apparently a sister language to XUL - but
> what about XPCOM? It is just as (or more?) important as XUL isn't it?
If there is a replacement technogoly for XUL overlays (as in: HTML overlays? anyone?)
then I would say, yes XPCOM is much more important. However overlaying is a really
important way of augmenting the UI in a deep way _quickly_. You can certainly do this
through DOM manipulation (e.g. inject a button at a time) but there is a much higher
As regards XPCOM, that'sss an absolute essential for low level access to objects that
aren't exposed such as the ones listed here:
Here is what I use in Thunderbird for just one of my Addons (quickFilters) :
nsIExtensionManager (I know it's deprecated, just using it for older applications for backwards compatibility)
so that's just for a single Addon. If they were pulled I would have to look for
suitable APIs, and then do a /lot /of rewriting. If some were not supported in APIs I
would have ti abandon functionality, to the point where the Addon might become so
lightweight that it wouldn't warrant the installation. So in my mind XPCOM is
indispensable right now. I can do the same search on my Firefox Addons, and there
would be probably a smaller list of XPCOM interfaces but they would also most likelly
be even more substantial for their functionality.
> Also - are XUL/XPCOM an integral part of Gecko? Or are they separate?
>> What *has* been announced is the depreciation of non-webextension addons in Firefox
>> from Firefox 57 onwards
>> (https://blog.mozilla.org/addons/2016/11/23/add-ons-in-2017/), but since
>> XUL itself is not going away, keeping them working in Thunderbird beyond
>> that point should be feasible.
> What was meant then by Mozilla's announcement of the deprecation of XUL/XBL/XPCOM?
> Either they are going away, or they aren't. Or maybe, they will be there, but the
> hooks will be removed for Firefox?
Don't worry, we Addon developers don't know either. I guess we are just waiting for
the day our Addons stop working (that happens from time to timee anyway) and find out
that we cannot repair them anymore because the available underlying technologies have
been "locked down".
At the moment the process for use Addon Devs is fairly straightforward: if a _single_
XPCOM interface is deprecated / removed, our beta users usually file a bug in our
Addons bug-trackers and then we find the newer / workaround XPCOM interface; I
usually fix stuff within 24 hours of reporting.
Of course if all XPCOM interfaces become _verboten_ we are simply royally fucked. In
my case I will start advocating for the use of Pale Moon. If it happens in Thunderbird
I will begrudgingly retreat to the Postbox code base (and keep hoping that there is
some sanity in the SeaMonkey crowd, which most likely is going to fork) and kiss any
potential income goodbye (Postbox is bad for monetisation, their Addon Dev support is
sketchy to put it very very mldly). But I think on that front we will be safe until
Thunderbird council finally decides on whether they must fork, or not.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the tb-planning