Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

The likely end of DownThemAll

downthemall.net

Post reply on HN
Print view View original

111–120 of 142 posts

Re: The likely end of DownThemAll

#111

Post by throwaway2048 »

pcwalton wrote: post #74
hyperion2010 wrote: post #45

This seems like a classic case if thinking people use your software for the core features you develop. I hate to break it to you but people don't use windows for the control panel. Firefox and other browsers have become development platforms and many of their "users" don't use their platform for its 'control panel,' they use it for some useful tool built on top of it. To use a linux kernel term, this breaks userspace…

> To use a linux kernel term, this breaks userspace (might be a sign that browsers have some serious OS envy). No, the equivalent of breaking userspace would be breaking the Web platform. This is more like breaking the in-kernel API for .ko modules—and the official Linux policy on this is [1]. Firefox has always been much less inclined to break its internal XPCOM APIs than the Linux kernel has been to break its inter…

The way you keep comparing firefox extensions to kernel modules seems really disingenuous, the paralels are weak at best.

Re: The likely end of DownThemAll

#112

Post by throwaway2048 »

Shebanator wrote: post #69
aaron695 wrote: post #48

Earlier quoted context omitted.

The main reason people install it I thought is because 1. It allows downloads to start and stop. No more 90% of that iso then having to start again. 2. It opens up 4 thingies on the file and downloads simultaneously. So 4 times quicker if the website is restricting bandwidth per connection.

With the new APIs, you should be able to have 4 web workers do the downloads in parallel still. (Based on how chrome handles such things)

web workers don't have anything except message passing ability to the main js thread, they cant open sockets, and they can modify the dom, they are nearly worthless.

Re: The likely end of DownThemAll

#113

Post by rhelmer »

nathanb wrote: post #101
rhelmer wrote: post #100

First, see https://billmccloskey.wordpress.com/2015/08/21/firefox-add-o... 1. these ideas are being announced far in advance of any actual changes 2. firefox devs (see link above) actively want to support current popular extensions, by adding to the Web Extension APIs In fact, you can participate in this discussion with Mozilla devs more directly: https://webextensions.uservoice.com/forums/315663-webextensi... Nobody…

Unintended consequences are still consequences. Most extensions are developed by volunteers; many of the rest are, at best, subsidized as a second job through donations or ad affiliates. These volunteers don't always have the time to fight for the APIs they need. DownThemAll has been around for a long time. I'm sure its developers are as passionate and involved as you will find anywhere in the Firefox ecosystem. But…

Good points, and I'll respond to the "sunk cost" bit by adding that backwards compatibility is a double-edged sword. My favorite pet example of this is MS versus Apple - the former has historically cared deeply about being backwards compatible, while the latter has gone through several hardware and software architecture changes that have required total rewrites from third-party developers.

The situation with Firefox is a little trickier, staying backwards-compatible for web content has always been an important goal, but anything living inside the browser chrome does not get the same assurances.

Right now extensions live somewhere between these two worlds, and we've had over a decade of experience with them so I think it's time to carve out their own space, with dependable APIs that are more stable than the internal browser APIs, but faster-moving and more privileged than the web.

Re: The likely end of DownThemAll

#114

Post by mook »

cwyers wrote: post #24
beloch wrote: post #12

From the Firefox announcement: Re: Why they are removing XUL: "XPCOM and XUL are two of the most fundamental technologies to Firefox. The ability to write much of the browser in JavaScript has been a huge advantage for Mozilla. It also makes Firefox far more customizable than other browsers. However, the add-on model that arose naturally from these technologies is extremely permissive. Add-ons have complete access to…

> add-ons that modify our code via regular expressions That's... actually kinda terrifying.

It is. And it's done because Firefox doesn't expose the right hooks and isn't interested in exposing them. They obviously know what's happening already.

From the addon's point of view, the option is do it via regular expressions or not at all; it turns out the most users don't actually care how things get done.

Re: The likely end of DownThemAll

#115

Post by mook »

brighteyes wrote: post #26
smacktoward wrote: post #11

Earlier quoted context omitted.

It also doesn't mean there will be one. Uncertainty about the future of an API is bad, it always causes developers who build on that API to panic and assume the worst.

Uncertainty is bad, but it's unavoidable in this case, for two reasons: * They need feedback from addon makers in order to design the new API. * Mozilla does all its work in the open anyhow. There is no way to avoid an announcement about an intention to change the API, before stating the API in full. Yes, it caused uncertainty, and that's a downside, but open development is generally worth it.

> There is no way to avoid an announcement about an intention to change the API, before stating the API in full. Yes, it caused uncertainty, and that's a downside, but open development is generally worth it.

It's quite possible to announce that they're starting to implement the new API, wait a year or two until it's capable enough, _then_ start talking about deprecating the existing one. Just like it was possible to finish implementing extension signing (or at least to the extent that people can automate signing) before deciding on a time frame to enforce it, or to get the automatic SSL certificate issuer (Let's Encrypt) working before talking about deprecating non-SSL HTTP traffic.

Basically, don't put the cart before the horse, let people implement transition plans. Wanting to have better things is fine; scaring people without having actionable mitigation strategies isn't so nice.

Re: The likely end of DownThemAll

#116

Post by mook »

mschuster91 wrote: post #46
Karunamon wrote: post #27

Something I just thought of... if these changes are presumably meant to keep malware addons out of the browser, then it's necessarily operating in an infected environment. (I.e. something already had the ability to do things in the context of the user without that user's permission, and we're just preventing it from doing this one thing via restricting what the user can do) In what way does this meaningfully secure t…

The problem these days is established extensions that get legitimately sold or their access data hacked, and malware rolled out to the users. Or extensions which actually do their job, but after a delay, e.g. a month, deploy the malware payload. Enforcing someone from Mozilla to take a look at the actual APIs used in the extension is a pretty reasonable way to prevent a lot of this. Also, disallowing local installs o…

> The problem these days is established extensions that get legitimately sold or their access data hacked, and malware rolled out to the users.

Published extensions on addons.mozilla.org (i.e. the built-in extension distribution channel) already go through a review for every update. Someone from Mozilla _already_ has to take a look.

Of course, the addon review queue is currently ~ 10 weeks (according to their blog, from Aug 12). Relative to the 6 week Firefox release cycle, it's like saying if Apple enforced application signing for OSX where you need to submit your app, wait a year and a half, then get a signed version back.

Re: The likely end of DownThemAll

#117

Post by brighteyes »

mook wrote: post #115
brighteyes wrote: post #26

Earlier quoted context omitted.

Uncertainty is bad, but it's unavoidable in this case, for two reasons: * They need feedback from addon makers in order to design the new API. * Mozilla does all its work in the open anyhow. There is no way to avoid an announcement about an intention to change the API, before stating the API in full. Yes, it caused uncertainty, and that's a downside, but open development is generally worth it.

> There is no way to avoid an announcement about an intention to change the API, before stating the API in full. Yes, it caused uncertainty, and that's a downside, but open development is generally worth it. It's quite possible to announce that they're starting to implement the new API, wait a year or two until it's capable enough, _then_ start talking about deprecating the existing one. Just like it was possible to…

I agree a more organized PR approach might be more effective, but it would be impossible to keep a secret like that when you're doing open development.

People would quickly ask "what is the long-term plan here?" and you can't lie to them.

Re: The likely end of DownThemAll

#118

Post by mook »

brighteyes wrote: post #117
mook wrote: post #115

Earlier quoted context omitted.

> There is no way to avoid an announcement about an intention to change the API, before stating the API in full. Yes, it caused uncertainty, and that's a downside, but open development is generally worth it. It's quite possible to announce that they're starting to implement the new API, wait a year or two until it's capable enough, _then_ start talking about deprecating the existing one. Just like it was possible to…

I agree a more organized PR approach might be more effective, but it would be impossible to keep a secret like that when you're doing open development. People would quickly ask "what is the long-term plan here?" and you can't lie to them.

> People would quickly ask "what is the long-term plan here?" and you can't lie to them.

Sure; but you wouldn't need to. Just don't have a time line set (as opposed to the 12 ~ 18 months set here). They've done it once with Jetpack already, that just didn't go anywhere because the APIs weren't flexible enough to actually not need all the underlying guts. Hopefully this one would have better results, but that requires lots of work on the part of Mozilla to actually implement enough API surface for the thing to be useful.

Re: The likely end of DownThemAll

#119

Post by brighteyes »

mook wrote: post #118
brighteyes wrote: post #117

Earlier quoted context omitted.

I agree a more organized PR approach might be more effective, but it would be impossible to keep a secret like that when you're doing open development. People would quickly ask "what is the long-term plan here?" and you can't lie to them.

> People would quickly ask "what is the long-term plan here?" and you can't lie to them. Sure; but you wouldn't need to. Just don't have a time line set (as opposed to the 12 ~ 18 months set here). They've done it once with Jetpack already, that just didn't go anywhere because the APIs weren't flexible enough to actually not need all the underlying guts. Hopefully this one would have better results, but that requires…

So you're suggesting they say "we intend to deprecate this feature", but not give a timeline?

It seems much more open and fair to give a timeline. That way it's predictable and lets people plan.

Re: The likely end of DownThemAll

#120

Post by mook »

brighteyes wrote: post #119
mook wrote: post #118

Earlier quoted context omitted.

> People would quickly ask "what is the long-term plan here?" and you can't lie to them. Sure; but you wouldn't need to. Just don't have a time line set (as opposed to the 12 ~ 18 months set here). They've done it once with Jetpack already, that just didn't go anywhere because the APIs weren't flexible enough to actually not need all the underlying guts. Hopefully this one would have better results, but that requires…

So you're suggesting they say "we intend to deprecate this feature", but not give a timeline? It seems much more open and fair to give a timeline. That way it's predictable and lets people plan.

> So you're suggesting they say "we intend to deprecate this feature", but not give a timeline?

Yes; but that only works if they don't actually _have_ a timeline. Do the necessary work to let people explore options, then evaluate and give a timeline (in the same order as what it took to get all that implemented).

The timeline currently is "you have 12 to 18 months, but can't actually start". That's pretty much a recipe for frustration.

Post reply on HN