]]>Comment on I Ain’t Dead by robceehttp://theunfocused.net/2013/02/14/i-aint-dead/#comment-1036
Thu, 14 Feb 2013 05:47:17 +0000http://theunfocused.net/?p=606#comment-1036I hope you’re feeling better and can get back to being your awesome bearded self real soon. Your forced “vacation” sounds awesome until I start to think about all the things you couldn’t do. Reading, coding, driving, watching movies, … Not to mention all the activities requiring some degree of physicality. Basically, everything.

get well soon (but don’t rush it!).

]]>Comment on Add-ons Manager API: Change in event order when restartless extensions are installed by Blair McBridehttp://theunfocused.net/2012/03/06/addons-manager-api-change/#comment-1035
Thu, 22 Mar 2012 11:43:00 +0000http://theunfocused.net/?p=579#comment-1035Update: This change will ship in Firefox update 14, which is scheduled to be released on 2012-07-17.
]]>Comment on The Add-ons Manager and I are rather good chums by moglyhttp://theunfocused.net/2012/01/05/the-add-ons-manager-and-i-are-rather-good-chums/#comment-1034
Fri, 13 Jan 2012 10:12:33 +0000http://theunfocused.net/?p=549#comment-1034Hi,

Filter Extension is great, but doesn’t work on last version of Firefox.

Do you works on the new version ?

Regards.

]]>Comment on The Add-ons Manager and I are rather good chums by mitchohttp://theunfocused.net/2012/01/05/the-add-ons-manager-and-i-are-rather-good-chums/#comment-1033
Sat, 07 Jan 2012 14:57:15 +0000http://theunfocused.net/?p=549#comment-1033Congrats Blair!
]]>Comment on The Add-ons Manager and I are rather good chums by Astarahttp://theunfocused.net/2012/01/05/the-add-ons-manager-and-i-are-rather-good-chums/#comment-1032
Fri, 06 Jan 2012 20:15:21 +0000http://theunfocused.net/?p=549#comment-1032How difficult would it be for the moz devs to provide ‘shim’ layer/routines if they muck with the interface too much ?

I’ve seen multiple extensions fail because the renamed the extension manager interface! Now of course it may have been done because the interface changed enough they didn’t want old routines calling the new interface with old params… but it seems like it would have been a ‘good idea’, to provide a compatibility routine…

Now to NOT have to maintain um…’N’ compat layers… , you might consider
1) marking an older interface ‘deprecated’, after 2-3 releases (still works, but issues a warning message that you can click on ‘click x to not see this again’, — but the user is warned that that extension isn’t being up updated, and they may have to deal with something.
2) break off shim layers into *extensions*.. i.e. if I’m a user that wants to run
an extension from 1.x, and shimming it into 10.x is costly, put it in an extension and only those who need that will incur the expense. The shim layers would have a list of which modules are using them and only those modules would incur expenses for the ‘shimmed’ functions…
—
The above should give the FF team the freedom to move forward, while providing acceptable alternatives for things they don’t want to include in the new version.

NOTE: Any solution in this area must be in place by the EOLife date for 3.6 (let’s be sensible, that’s where much of the incompat comes from).

Also note — if the FF devs want the freedom to redefine the interface at will, they also need to provide the SHIMS, if they break compat. Personally, I would like to see the Shim group as a separate but blocking entity from the feature group, so the feature group doesn’t feel constrained in thinking about how to implement the shim when they do a new feature, but that _may_ not be practical. But it might if the Shim group — when blocked, gets assistance from the feature group in fixing/implementing the needed shims. There is no requirement that the shim operate with the same speed, but unreasonable degradation should be considered ‘bad’ (I say, unreasonable, as if you move to a HW-based algorithm somewhere, where as the previous stuff, with more flexibility had to use SW, well… there will be a price… )….

But fixing ‘the addon-compat job CAN’T be 1 person’s job, that person needs to be able to ‘block’ release, until the appropriate shim code is written.

Note, in some or ‘many’ cases, nothing needs to be done other than fix the way version numbers are done. It used to be X.Y.Z, X was major changes, Very likely internal interface has changed. Y was for possible changes — but old stuff _should_ work (at most with minimal changes), and ‘Z’, bug fixes, no internal Calling changes.

Going back to a sensible version number scheme would likely help the issue, even if it meant doing a global reset from FF10 -> FFng-4.5, when I saw the version numbers jumping by major numbers every month, I thought, this was really going to kill the basis of FF’s popularity — the extensions — because extension writers can’t be full-time employees writing their extensions; they don’t get paid enough to be that.

————–
Another though — maybe Moz might consider providing a more formal extension source repo — I know they ‘usually’ have a previous versions (is that always the case now?, cuz I remember times in the past when it wasn’t and I had to beg the author for a previous version)…

But it might make it easier for people to fork and submit patches back to a extension maintainer — and if they don’t want them, then just make a fork!…(or a spoon?)…

]]>Comment on The Add-ons Manager and I are rather good chums by Weshttp://theunfocused.net/2012/01/05/the-add-ons-manager-and-i-are-rather-good-chums/#comment-1031
Wed, 04 Jan 2012 16:26:47 +0000http://theunfocused.net/?p=549#comment-1031You’re here to kick ass and fix bugs, and you’re all out of ass?
]]>Comment on Solving Firefox’s add-on compatibility problem by The Add-ons Manager and I are rather good chums « Blair’s Brainhttp://theunfocused.net/2011/11/19/solving-firefoxs-add-on-compatibility-problem/#comment-1030
Wed, 04 Jan 2012 14:24:30 +0000http://theunfocused.net/?p=518#comment-1030[...] a third of all the unit tests for the Add-ons Manager. Okay, maybe that part wasn't so fun… but solving the add-on compatibility problem [...]
]]>Comment on Solving Firefox’s add-on compatibility problem by arthurz1http://theunfocused.net/2011/11/19/solving-firefoxs-add-on-compatibility-problem/#comment-1029
Sat, 24 Dec 2011 09:58:56 +0000http://theunfocused.net/?p=518#comment-1029good news firefox aurora makes addons compatible by default
]]>Comment on Solving Firefox’s add-on compatibility problem by Firefox Add-On Compatibility | eschew it allhttp://theunfocused.net/2011/11/19/solving-firefoxs-add-on-compatibility-problem/#comment-1028
Thu, 22 Dec 2011 04:27:44 +0000http://theunfocused.net/?p=518#comment-1028[...] looks like Firefox is moving to a compatible-by-default model for extensions. I find this interesting, since I proposed this back in 2004 to no [...]
]]>