Removal of nsILocalFile and other interfaces, was: Upcoming change to fixIterator function in iteratorUtils.jsm

Joshua Cranmer 🐧 pidgeot18 at gmail.com
Tue Aug 8 18:33:07 UTC 2017


On 8/8/2017 1:09 PM, Ben Bucksch wrote:
> I would suggest to keep such interfaces. an empty interface is not 
> really a maintenance burden. and adding this file will be 100 times 
> easier than fixing all callers, even if it's just a replacement.
>
> this is particularly true for extensions without maintainer. it's the 
> user that counts, not who is at fault. this is a relatively easy way 
> to avoid unnecessary breakage.
>
> you might be able to just undo these m-c commits, or (to avoid changes 
> to m-c) move the IDL files to a new dir in mailnews/compat/src/public/.

I'm going to push back on this. nsILocalFile was blanked out on 
2012-04-05. That's 5 years it's done absolutely nothing, and any 
extension maintained in the intervening period has had more than ample 
opportunity to fix it. It's also wrong to say that it's not a 
maintenance burden. It is: we'd have to make the ns*File implementations 
support nsILocalFile for its QI support. This requires forking 
mozilla-central or maintaining a copy of a forked file. If you don't 
maintain the nsILocalFile QI support, then you'd *still* break most of 
the extensions that would hypothetically use it. You're adding 
maintenance burden for literally zero gain. Also, the interface itself 
has seen two substantive commits in the intervening period, necessitated 
by XPIDL semantic changes (the likes of which should not be ruled out 
for the future).

Finally, we've had long discussions about the impacts of technical debt 
on our codebase. Advocating for keeping a compatibility shim that 
Mozilla is unwilling to keep requires substantial justification. 
Certainly, it requires far more than "maybe it will keep unmaintained 
5-year old addons working."

-- 
Joshua Cranmer
Thunderbird and DXR developer
Source code archæologist



More information about the tb-planning mailing list