5 ms·

As people have been saying in the thread that links to the announcement, it is not at all clear that extensions that today can do things in Firefox that are not

by dangoor 11y ago

As people have been saying in the thread that links to the announcement, it is not at all clear that extensions that today can do things in Firefox that are not possible in Chrome will be unable to do those things in the future. The mechanism for things like changing tab management and such would surely change, but that doesn't mean there won't be one.

smacktoward 11y ago
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.
- brighteyes 11y ago
  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.
  - vanderZwan 11y ago
    With that in mind it's both expected and perfectly fine if addon developers are up in arms about this change, as long as it doesn't stop Mozilla from designing a new API in the open while listening to the developers. Hostile feedback is still feedback.
  - mook 11y ago
    > 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.
    - brighteyes 11y ago
      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.
      - mook 11y ago
        > 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.
        brighteyes 11y ago
        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.
        mook 11y ago
        > 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.
        brighteyes 11y ago
        I guess it's a matter of opinion, but I greatly prefer it they way they did it. Announcing "this is going away" without a timeline would make me worry "when? now? in a month?" Instead, by saying "12 to 18 months", I know this is a long-term thing and I can plan for it. The timeline is very useful information.
the8472 11y ago
The concern is basically that they may cover most bases, but will decline to allow some things that could be done today. Even if they'll support the popular use-cases. What about the fringe uses?
steve-howard 11y ago
They say they're going to try and cover all the use cases with a new API, but it's clear that that API is in its infancy. Even if it were ready to go today, this would require authors to rewrite their extensions, which will mean that some stable extensions will fall through the cracks.

by dangoor 11y ago

smacktoward 11y ago

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.

brighteyes 11y ago
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.
- vanderZwan 11y ago
  With that in mind it's both expected and perfectly fine if addon developers are up in arms about this change, as long as it doesn't stop Mozilla from designing a new API in the open while listening to the developers. Hostile feedback is still feedback.
- mook 11y ago
  > 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.
  - brighteyes 11y ago
    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.
    - mook 11y ago
      > 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.
      - brighteyes 11y ago
        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.
        mook 11y ago
        > 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.
        brighteyes 11y ago
        I guess it's a matter of opinion, but I greatly prefer it they way they did it. Announcing "this is going away" without a timeline would make me worry "when? now? in a month?" Instead, by saying "12 to 18 months", I know this is a long-term thing and I can plan for it. The timeline is very useful information.

the8472 11y ago

The concern is basically that they may cover most bases, but will decline to allow some things that could be done today. Even if they'll support the popular use-cases. What about the fringe uses?

steve-howard 11y ago

They say they're going to try and cover all the use cases with a new API, but it's clear that that API is in its infancy. Even if it were ready to go today, this would require authors to rewrite their extensions, which will mean that some stable extensions will fall through the cracks.