Comments on: Do we need extension dependencies? http://www.oxymoronical.com/blog/2010/01/Do-we-need-extension-dependencies Spouting nonsense from the depths of my spare time Sat, 14 Jan 2012 22:20:26 +0000 hourly 1 http://wordpress.org/?v=3.3.1 By: orate http://www.oxymoronical.com/blog/2010/01/Do-we-need-extension-dependencies#comment-52811 orate Sun, 18 Jul 2010 06:58:13 +0000 http://www.oxymoronical.com/?p=683#comment-52811 why not? one word: Piro https://addons.mozilla.org/en-US/firefox/user/9480 Fractionalized features across multiple extensions. Dropping these features will lead to greater extension bloatware (tendancies) ugh why not? one word:

Piro

https://addons.mozilla.org/en-US/firefox/user/9480

Fractionalized features across multiple extensions.

Dropping these features will lead to greater extension bloatware (tendancies)

ugh

]]> By: Nathan http://www.oxymoronical.com/blog/2010/01/Do-we-need-extension-dependencies#comment-44637 Nathan Thu, 01 Apr 2010 16:03:33 +0000 http://www.oxymoronical.com/?p=683#comment-44637 Just an observation, but wouldn't this have been a moot point in the old "install.js" days? This does raise the question of why this was deprecated. The RDF version of installation is warm and fluffy and "easy", but it also lacks a lot of functionality, IMO. I do not see there being a "security risk" with install.js primarily because once an extension is installed, the JavaScript therein has unrestricted access to XPConnect, anyway. Here's a real-world example illustrating the problem. I'm writing a new extension for Firefox 3.x for a contract job. The extension *requires* that Java Applets be available. How do I make my XPI test for the dependency? Good luck with that. As a result, I have to end up writing a bunch of tests on the browser-side itself before even offering the XPI for installation. Although there is a solution, it's a butt-ugly one. Just an observation, but wouldn’t this have been a moot point in the old “install.js” days? This does raise the question of why this was deprecated. The RDF version of installation is warm and fluffy and “easy”, but it also lacks a lot of functionality, IMO. I do not see there being a “security risk” with install.js primarily because once an extension is installed, the JavaScript therein has unrestricted access to XPConnect, anyway.

Here’s a real-world example illustrating the problem. I’m writing a new extension for Firefox 3.x for a contract job. The extension *requires* that Java Applets be available. How do I make my XPI test for the dependency? Good luck with that.

As a result, I have to end up writing a bunch of tests on the browser-side itself before even offering the XPI for installation. Although there is a solution, it’s a butt-ugly one.

]]> By: Jonathan Morgan http://www.oxymoronical.com/blog/2010/01/Do-we-need-extension-dependencies#comment-39610 Jonathan Morgan Thu, 14 Jan 2010 12:08:39 +0000 http://www.oxymoronical.com/?p=683#comment-39610 For extensions in other languages (e.g. using PyXPCOM) a dependency for an extension providing that other language is going to be necessary. I'm not sure how much we really want to encourage this though (I like Python myself, but it adds a fairly big burden on the browser having a huge monolithic platform specific extension). For extensions in other languages (e.g. using PyXPCOM) a dependency for an extension providing that other language is going to be necessary. I’m not sure how much we really want to encourage this though (I like Python myself, but it adds a fairly big burden on the browser having a huge monolithic platform specific extension).

]]> By: Brett Zamir http://www.oxymoronical.com/blog/2010/01/Do-we-need-extension-dependencies#comment-39507 Brett Zamir Wed, 13 Jan 2010 03:11:53 +0000 http://www.oxymoronical.com/?p=683#comment-39507 Although I can understand your temporarily taking it out, I truly hope you will add a revamped version in the future--one which, including at the AMO site, automatically downloads missing dependencies, at least with user permission. That part is critical. I would also like to see the ability to share smaller dependencies such as JavaScript modules (if not components). I think such modularization would greatly inspire more and faster innovation, code reuse, collaboration (since people are motivated to report bugs, etc.), and support users adding more extensions, since they won't notice as much of a performance impact with modules being shared. Besides this, I think the awareness that one's extension's APIs can be exposed can lead to more interesting extension interactions (e.g., if Lightning exposed its APIs, an extension could make its own interface to add events). As you make any move to Jetpack, I also really hope other rich support will not be dropped. Please don't dumb down things, whether due to making APIs more accessible or for security! While many of the masses might not care (or think they don't care) about power features, a lot of us got into Firefox and develop for it because of its powerful platform. If there's anything that could ever kill Firefox, it is driving away developers with too many platform feature regressions (though I don't think this particular case would be a very significant one, I am nervous about the herd going this route, as I know some can take a "let's protect them from themselves" attitude which may be ok for the web, but not for trusted extensions if it means less powerful APIs; likewise, I've also seen even top and otherwise admirable developers be a little patronizing in assuming they alone know what's good for the web and use that to justify neglecting bugs or dropping niche but well-loved features). "It's the Add-on power, dummies!" ;) You can't please anyone, no doubt, but hopefully one can try... I think extension dependencies (if done thoroughly) is very directly related to enabling that... Although I can understand your temporarily taking it out, I truly hope you will add a revamped version in the future–one which, including at the AMO site, automatically downloads missing dependencies, at least with user permission. That part is critical.

I would also like to see the ability to share smaller dependencies such as JavaScript modules (if not components). I think such modularization would greatly inspire more and faster innovation, code reuse, collaboration (since people are motivated to report bugs, etc.), and support users adding more extensions, since they won’t notice as much of a performance impact with modules being shared. Besides this, I think the awareness that one’s extension’s APIs can be exposed can lead to more interesting extension interactions (e.g., if Lightning exposed its APIs, an extension could make its own interface to add events).

As you make any move to Jetpack, I also really hope other rich support will not be dropped. Please don’t dumb down things, whether due to making APIs more accessible or for security! While many of the masses might not care (or think they don’t care) about power features, a lot of us got into Firefox and develop for it because of its powerful platform. If there’s anything that could ever kill Firefox, it is driving away developers with too many platform feature regressions (though I don’t think this particular case would be a very significant one, I am nervous about the herd going this route, as I know some can take a “let’s protect them from themselves” attitude which may be ok for the web, but not for trusted extensions if it means less powerful APIs; likewise, I’ve also seen even top and otherwise admirable developers be a little patronizing in assuming they alone know what’s good for the web and use that to justify neglecting bugs or dropping niche but well-loved features). “It’s the Add-on power, dummies!” ;)

You can’t please anyone, no doubt, but hopefully one can try… I think extension dependencies (if done thoroughly) is very directly related to enabling that…

]]> By: Mossop http://www.oxymoronical.com/blog/2010/01/Do-we-need-extension-dependencies#comment-39466 Mossop Tue, 12 Jan 2010 17:27:18 +0000 http://www.oxymoronical.com/?p=683#comment-39466 It does become a complete nightmare if you start considering multiple add-on types. Imagine a scenario where we support Jetpack like features that don't require a restart to use. If we allow XPI extensions to depend on Jetpack features then all of a sudden you can't disable/uninstall the Jetpack feature without a restart since it must disable the XPI extension. It does become a complete nightmare if you start considering multiple add-on types. Imagine a scenario where we support Jetpack like features that don’t require a restart to use. If we allow XPI extensions to depend on Jetpack features then all of a sudden you can’t disable/uninstall the Jetpack feature without a restart since it must disable the XPI extension.

]]> By: Mossop http://www.oxymoronical.com/blog/2010/01/Do-we-need-extension-dependencies#comment-39464 Mossop Tue, 12 Jan 2010 17:23:52 +0000 http://www.oxymoronical.com/?p=683#comment-39464 My own experiences of apt and yum say that this isn't a solved problem at all. It is fine so long as you are working from a single repository where all of the dependencies are managed properly (and even that isn't necessarily true of the Linux distributions). As soon as you start to use repositories from different people you get conflicting dependencies that make it impossible to install or uninstall anything. To take your example I could easily predict that different extensions would end up requiring different versions of jQuery, we can only install one version of an extension at a time so you end up in a place where installing one extension necessitates the uninstall or disabling of another. But this is besides the point. Even if we had an example of a perfectly working system and we knew how to represent the complications in a way that the user could understand this would still not be a solved problem, there would still be work to implement that in Firefox and as I've said right now that is not on the cards. My own experiences of apt and yum say that this isn’t a solved problem at all. It is fine so long as you are working from a single repository where all of the dependencies are managed properly (and even that isn’t necessarily true of the Linux distributions). As soon as you start to use repositories from different people you get conflicting dependencies that make it impossible to install or uninstall anything. To take your example I could easily predict that different extensions would end up requiring different versions of jQuery, we can only install one version of an extension at a time so you end up in a place where installing one extension necessitates the uninstall or disabling of another.

But this is besides the point. Even if we had an example of a perfectly working system and we knew how to represent the complications in a way that the user could understand this would still not be a solved problem, there would still be work to implement that in Firefox and as I’ve said right now that is not on the cards.

]]> By: James http://www.oxymoronical.com/blog/2010/01/Do-we-need-extension-dependencies#comment-39458 James Tue, 12 Jan 2010 16:20:00 +0000 http://www.oxymoronical.com/?p=683#comment-39458 Dependencies would be useful to cut down on duplication - quite a few extensions ship jquery for example, having a common extension for that would be nice. Dependency resolution is a solved problem, see apt or yum. Dependencies would be useful to cut down on duplication – quite a few extensions ship jquery for example, having a common extension for that would be nice. Dependency resolution is a solved problem, see apt or yum.

]]> By: Rob Campbell http://www.oxymoronical.com/blog/2010/01/Do-we-need-extension-dependencies#comment-39454 Rob Campbell Tue, 12 Jan 2010 15:23:37 +0000 http://www.oxymoronical.com/?p=683#comment-39454 This works as long as you're the publisher of both addons. If you want to rely on another that you *don't* own, this becomes more problematic. This works as long as you’re the publisher of both addons. If you want to rely on another that you *don’t* own, this becomes more problematic.

]]> By: Wladimir Palant http://www.oxymoronical.com/blog/2010/01/Do-we-need-extension-dependencies#comment-39174 Wladimir Palant Sat, 09 Jan 2010 14:13:34 +0000 http://www.oxymoronical.com/?p=683#comment-39174 Why should I require the user to install a bundle if in most cases he already has the required extension? Not to mention that I am not aware of any way to publish an extension bundle on AMO - and that's still the main distribution channel for extensions. Why should I require the user to install a bundle if in most cases he already has the required extension? Not to mention that I am not aware of any way to publish an extension bundle on AMO – and that’s still the main distribution channel for extensions.

]]> By: Wladimir Palant http://www.oxymoronical.com/blog/2010/01/Do-we-need-extension-dependencies#comment-39173 Wladimir Palant Sat, 09 Jan 2010 14:10:14 +0000 http://www.oxymoronical.com/?p=683#comment-39173 Malte, querying AMO was the idea from the very start - but some features turn out everything but simple when you start thinking about the details. In particular, this one has lots of nasty edge cases that need to be considered (nested dependencies, circular dependencies, updates for an extension but not its dependencies etc. etc.). Given the current state of the add-on manager I can understand that nobody wants to solve all these issues just yet. But - sure, I would be glad if somebody did nevertheless. Malte, querying AMO was the idea from the very start – but some features turn out everything but simple when you start thinking about the details. In particular, this one has lots of nasty edge cases that need to be considered (nested dependencies, circular dependencies, updates for an extension but not its dependencies etc. etc.). Given the current state of the add-on manager I can understand that nobody wants to solve all these issues just yet. But – sure, I would be glad if somebody did nevertheless.

]]>