What happened to hiring an architect?

Axel Grude 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>
> *To:*Tb-planning
> *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 
"design threshold".

As regards XPCOM, that'sss an absolute essential for low level access to objects that 
aren't exposed such as the ones listed here:

https://developer.mozilla.org/en-US/docs/Mozilla/Tech/XPCOM/Reference/Interface

Here is what I use in Thunderbird for just one of my Addons (quickFilters) :

nsIAlertsService
nsIAppShellService
nsIClipboardHelper
nsICollection
nsIConsoleService
nsIDOMElement
nsIEditor
nsIExtensionManager  (I know it's deprecated, just using it for older applications for backwards compatibility)
nsIExternalProtocolService
nsIFileInputStream
nsIFileOutputStream
nsIFilePicker
nsIFileURL
nsIFocusManager
nsIInterfaceRequestor
nsIIOService
nsIIOService
nsILocalFile
nsIMsgAccount
nsIMsgAccountManager
nsIMsgCompFields
nsIMsgCopyService
nsIMsgDBHdr
nsIMsgFilterList
nsIMsgFolder
nsIMsgGlobalIndex
nsIMsgHeaderParser
nsIMsgIdentity
nsIMsgIncomingServer
nsIMutableArray
nsIObserverService
nsIPrefBranch
nsIPromptService
nsIProperties
nsIRDFResource
nsIScriptableUnicodeConverter
nsIScriptError
nsIStringBundleService
nsIStyleSheetService
nsISupportsArray
nsISupportsString
nsITransferable
nsITreeBoxObject
nsIURI
nsIUrlListener
nsIVersionComparator
nsIWindowMediator
nsIWindowWatcher
nsIXMLHttpRequest
nsIXULAppInf

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.

hth,
   Axel



-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/tb-planning/attachments/20161216/98bb2cec/attachment-0001.html>


More information about the tb-planning mailing list