The future of extensions
johnjbarton
answer rather than creating a misunderstanding. So as a preface, my
motivation is sustaining Firebug and Chromebug that I work on, and a lot
of other extensions that I use.
The current outlook for extensions is bleak. We have heard about two
decisions made by someone somewhere, one to re-architect XUL
applications into multiprocess and one to replace the current extension
system with jetpack. A third major architectural change is being
discussed on js-engine
http://groups.google.com/group/mozilla.dev.tech.js-engine/browse_thread/thread/7a173ebda62f32b1#
(and I'm grateful that this on is being discussed).
Along the way we've seen a few reassuring posts that extensions will be
taken care of. On this point I am not so concerned: the installed base
of extensions is large and it's very unlikely that dramatic changes will
actually occur.
But it seems very likely that we'll have to invest lots of time in
unproductive discussions because migration of the current extension
system is not being discussed. In fact I don't think there is anyone
from the core team who represents us, which is itself pretty weird.
(Many core developers help us and push for our issues, but it's not the
same).
How can we create plan for the future of extensions and how can
extension authors participate in that plan?
jjb
chris hofmann
On 2/12/10 10:06 AM, Mike Shaver wrote:
> On Fri, Feb 12, 2010 at 12:56 PM, johnjbarton
> <johnj...@johnjbarton.com> wrote:
>
>> But it seems very likely that we'll have to invest lots of time in
>> unproductive discussions because migration of the current extension system
>> is not being discussed.
>>
> desire or even tentative planning.
Shaver is mostly right, but there is also a good deal of investigation
and planning still going on about both API set and architecture for
jetpack so communication will be a bit rough until that gets locked down
a bit more.
A couple of places to learn more or participate in what jetpack is doing are
1) the news group
http://groups.google.com/group/mozilla-labs-jetpack?hl=en
<http://groups.google.com/group/mozilla-labs-jetpack?hl=en>
and
2) if you know about or spot extra dependencies that jetpack has, or
should have on the platform they should get added to
https://bugzilla.mozilla.org/show_bug.cgi?id=543856
upcoming highlights in the newsgroup are that myk will be proposing the
first phase APIs for the next round of jetpack development. from there
implementation, testing and evaluation about exactly what will be needed
from gecko and toolkit will start to happen.
Its also hard to discuss the migration of current extentions until a
plan around what they would migrate too becomes just a bit more clear.
But be assured, everyone working on the jetpack APIs and architecture
understands that easing the migration path from current addons is a goal
for jetpack, and that solving the constant compatibility problems that
addons face will trying to track with Firefox is also a high priority
goal. the strategy is to make this migration possible for a few, and
then eventually a large sets of addons.
-chofmann
> It is a real problem, and you're
> right to raise it, but I think that things are not as bleak as they
> (quite reasonably) appear.
>
> I'll see what I can do to get that communication goosed, as they say.
>
> Mike
> _______________________________________________
> dev-planning mailing list
> dev-pl...@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-planning
>
johnjbarton
>
> On 2/12/10 10:06 AM, Mike Shaver wrote:
>> On Fri, Feb 12, 2010 at 12:56 PM, johnjbarton
>> <johnj...@johnjbarton.com> wrote:
>>> But it seems very likely that we'll have to invest lots of time in
>>> unproductive discussions because migration of the current extension
>>> system
>>> is not being discussed.
>> I think this is a problem of communication, and not one of intent,
>> desire or even tentative planning.
>
> Shaver is mostly right, but there is also a good deal of investigation
> and planning still going on about both API set and architecture for
> jetpack so communication will be a bit rough until that gets locked down
> a bit more.
But that is exactly what I am complaining about.
>
> A couple of places to learn more or participate in what jetpack is doing
> are
>
> 1) the news group
> http://groups.google.com/group/mozilla-labs-jetpack?hl=en
> <http://groups.google.com/group/mozilla-labs-jetpack?hl=en>
Tried that, it's read-only.
>
> and
>
> 2) if you know about or spot extra dependencies that jetpack has, or
> should have on the platform they should get added to
> https://bugzilla.mozilla.org/show_bug.cgi?id=543856
I have not yet figured out why I care about jetpack. Yes it has been
anointed as the One True Future, but that's not the same as being a
practical solution.
>
> upcoming highlights in the newsgroup are that myk will be proposing the
> first phase APIs for the next round of jetpack development. from there
> implementation, testing and evaluation about exactly what will be needed
> from gecko and toolkit will start to happen.
I think this is a lot of carts and no horse. Consider:
https://wiki.mozilla.org/Labs/Jetpack/Reboot/Architecture_Overview
>
> Its also hard to discuss the migration of current extentions until a
> plan around what they would migrate too becomes just a bit more clear.
You've already made the decision that current extensions will be
obligated to recode to jetpack. Since I don't consider that to be
feasible, I'm not very interested in such a migration.
> But be assured, everyone working on the jetpack APIs and architecture
> understands that easing the migration path from current addons is a goal
> for jetpack, and that solving the constant compatibility problems that
> addons face will trying to track with Firefox is also a high priority
> goal. the strategy is to make this migration possible for a few, and
> then eventually a large sets of addons.
I am not assured because I see nothing to suggest this topic has even
been considered by jetpack team. It's perfectly fine to go off an create
your own world and developers will adopt your platform to the extent it
suits them. It's another to say you will take on the responsibility for
migration. These are not the same.
A much better solution would split jetpack into infrastructure work
shared with extensions and jetpack-specific work for new development.
The infrastructure work would look and act like 'platform' and would
explicitly aim for extension adoption and step-wise migration. The
jetpack specific work would aim for new adopters and concentrate on the
original vision of jetpack as a lightweight addon developer feature.
jjb
Shawn Wilsher
> You've already made the decision that current extensions will be
> obligated to recode to jetpack. Since I don't consider that to be
> feasible, I'm not very interested in such a migration.
that current-style extensions are not going away anytime soon. I know
you read that because you had comments on that too.
/sdwilsh
chris hofmann
On 2/12/10 12:14 PM, johnjbarton wrote:
> On 2/12/2010 11:40 AM, chris hofmann wrote:
>>
>> On 2/12/10 10:06 AM, Mike Shaver wrote:
>>> On Fri, Feb 12, 2010 at 12:56 PM, johnjbarton
>>> <johnj...@johnjbarton.com> wrote:
>>>> But it seems very likely that we'll have to invest lots of time in
>>>> unproductive discussions because migration of the current extension
>>>> system
>>>> is not being discussed.
>>> I think this is a problem of communication, and not one of intent,
>>> desire or even tentative planning.
>>
>> Shaver is mostly right, but there is also a good deal of investigation
>> and planning still going on about both API set and architecture for
>> jetpack so communication will be a bit rough until that gets locked down
>> a bit more.
>
> But that is exactly what I am complaining about.
>
Can communication be better? Yes it can, and yes it will be.
>>
>> A couple of places to learn more or participate in what jetpack is doing
>> are
>>
>> 1) the news group
>> http://groups.google.com/group/mozilla-labs-jetpack?hl=en
>> <http://groups.google.com/group/mozilla-labs-jetpack?hl=en>
>
> Tried that, it's read-only.
Check your settings. Here is what I see set up and its set way for
defenses against spam. If there are any of your messages sitting in
queue I'll find out who can release them. send me mail.
*
Access*
Anybody can view group content
Only members can view group members list
Anyone can join
Only managers can create and edit pages
Only managers can upload files
Only members can post
Messages from new members are moderated
>>
>> and
>>
>> 2) if you know about or spot extra dependencies that jetpack has, or
>> should have on the platform they should get added to
>> https://bugzilla.mozilla.org/show_bug.cgi?id=543856
>
> I have not yet figured out why I care about jetpack. Yes it has been
> anointed as the One True Future, but that's not the same as being a
> practical solution.
>>
>> upcoming highlights in the newsgroup are that myk will be proposing the
>> first phase APIs for the next round of jetpack development. from there
>> implementation, testing and evaluation about exactly what will be needed
>> from gecko and toolkit will start to happen.
>
> I think this is a lot of carts and no horse. Consider:
> https://wiki.mozilla.org/Labs/Jetpack/Reboot/Architecture_Overview
>
In these two comments it seems like your saying "I want a solution that
fits all my needs, and I want it now!" That's a bit tiresome if the
solution is in process of being developed. Lets try to keep the
discussion on track and understand the plan is under develop. You can
participate in it by making suggestions more along the lines that you
did below.
>>
>> Its also hard to discuss the migration of current extentions until a
>> plan around what they would migrate too becomes just a bit more clear.
>
> You've already made the decision that current extensions will be
> obligated to recode to jetpack. Since I don't consider that to be
> feasible, I'm not very interested in such a migration.
If the problem is that we have no compatibility layer right now, and
addons can reach into any part of the platform including:
-areas that are frozen and will remain so
-areas that have been frozen but we have plans to change
-areas that are not frozen and were intended to be accesses
If addons want to get out of compatibility hell then a recoding effort
will be required. The goal is to make this only one recoding effort, or
the absolute fewest possible as we get to a stable set of APIs that
provide the abstraction needed to hide the problem listed above in items
2 and 3.
The current addons face two tough choices. Try and chase compatibility
problems as they have for the last 5 years, or switch over to an API
that hides the details of the evolving platform. If you have any ways
around these choices lets here about them.
>
>> But be assured, everyone working on the jetpack APIs and architecture
>> understands that easing the migration path from current addons is a goal
>> for jetpack, and that solving the constant compatibility problems that
>> addons face will trying to track with Firefox is also a high priority
>> goal. the strategy is to make this migration possible for a few, and
>> then eventually a large sets of addons.
>
> I am not assured because I see nothing to suggest this topic has even
> been considered by jetpack team. It's perfectly fine to go off an
> create your own world and developers will adopt your platform to the
> extent it suits them. It's another to say you will take on the
> responsibility for migration. These are not the same.
>
> A much better solution would split jetpack into infrastructure work
> shared with extensions and jetpack-specific work for new development.
> The infrastructure work would look and act like 'platform' and would
> explicitly aim for extension adoption and step-wise migration. The
> jetpack specific work would aim for new adopters and concentrate on
> the original vision of jetpack as a lightweight addon developer feature.
>
Some of the ideas being kicked around would allow for this the way I
understand things that would be developed as jetpack modules. But it
would mean your going to have to refactor and change code in your addon.
-chofmann
johnjbarton
Ok sooner or later. Given how much code we have, we need a long run way
and waypoints to succeed.
Plus I'm not really talking about jetpack. The multi-thread/multiprocess
issues need discussion so we know what to do.
jjb
>
> /sdwilsh
>
johnjbarton
>
> On 2/12/10 12:14 PM, johnjbarton wrote:
>> On 2/12/2010 11:40 AM, chris hofmann wrote:
>>> A couple of places to learn more or participate in what jetpack is doing
>>> are
>>>
>>> 1) the news group
>>> http://groups.google.com/group/mozilla-labs-jetpack?hl=en
>>> <http://groups.google.com/group/mozilla-labs-jetpack?hl=en>
>>
>> Tried that, it's read-only.
> Check your settings. Here is what I see set up and its set way for
...
My apology for be abrupt. I meant: posts to that newsgroup do not create
dialog.
...
>>> 2) if you know about or spot extra dependencies that jetpack has, or
>>> should have on the platform they should get added to
>>> https://bugzilla.mozilla.org/show_bug.cgi?id=543856
>>
>> I have not yet figured out why I care about jetpack. Yes it has been
>> anointed as the One True Future, but that's not the same as being a
>> practical solution.
>>>
>>> upcoming highlights in the newsgroup are that myk will be proposing the
>>> first phase APIs for the next round of jetpack development. from there
>>> implementation, testing and evaluation about exactly what will be needed
>>> from gecko and toolkit will start to happen.
>>
>> I think this is a lot of carts and no horse. Consider:
>> https://wiki.mozilla.org/Labs/Jetpack/Reboot/Architecture_Overview
>>
> In these two comments it seems like your saying "I want a solution that
> fits all my needs, and I want it now!" That's a bit tiresome if the
> solution is in process of being developed. Lets try to keep the
> discussion on track and understand the plan is under develop. You can
> participate in it by making suggestions more along the lines that you
> did below.
I want an architecture discussion and a give-and-take on a migration
pathway. Let's try to have any discussion!
>>>
>>> Its also hard to discuss the migration of current extentions until a
>>> plan around what they would migrate too becomes just a bit more clear.
>>
>> You've already made the decision that current extensions will be
>> obligated to recode to jetpack. Since I don't consider that to be
>> feasible, I'm not very interested in such a migration.
> If the problem is that we have no compatibility layer right now, and
> addons can reach into any part of the platform including:
>
> -areas that are frozen and will remain so
> -areas that have been frozen but we have plans to change
> -areas that are not frozen and were intended to be accesses
>
> If addons want to get out of compatibility hell then a recoding effort
> will be required. The goal is to make this only one recoding effort, or
> the absolute fewest possible as we get to a stable set of APIs that
> provide the abstraction needed to hide the problem listed above in items
> 2 and 3.
>
> The current addons face two tough choices. Try and chase compatibility
> problems as they have for the last 5 years, or switch over to an API
> that hides the details of the evolving platform. If you have any ways
> around these choices lets here about them.
As an author of several addons and in frequent discussions with other
addon authors, compatibility problems of the kind jetpack can solve
don't range in the top 10 issues. This is a problem for firefox, not for
addon authors.
You're proposing a vast amount of work for a modest gain. I would not
hesitate to say I would not recode for this gain.
>
>>
>>> But be assured, everyone working on the jetpack APIs and architecture
>>> understands that easing the migration path from current addons is a goal
>>> for jetpack, and that solving the constant compatibility problems that
>>> addons face will trying to track with Firefox is also a high priority
>>> goal. the strategy is to make this migration possible for a few, and
>>> then eventually a large sets of addons.
>>
>> I am not assured because I see nothing to suggest this topic has even
>> been considered by jetpack team. It's perfectly fine to go off an
>> create your own world and developers will adopt your platform to the
>> extent it suits them. It's another to say you will take on the
>> responsibility for migration. These are not the same.
>>
>> A much better solution would split jetpack into infrastructure work
>> shared with extensions and jetpack-specific work for new development.
>> The infrastructure work would look and act like 'platform' and would
>> explicitly aim for extension adoption and step-wise migration. The
>> jetpack specific work would aim for new adopters and concentrate on
>> the original vision of jetpack as a lightweight addon developer feature.
>>
> Some of the ideas being kicked around would allow for this the way I
> understand things that would be developed as jetpack modules. But it
> would mean your going to have to refactor and change code in your addon.
Where is this kicking happening?
jjb
Al Billings
> > A couple of places to learn more or participate in what jetpack is doing
> > are
>
> > 1) the news group
> >http://groups.google.com/group/mozilla-labs-jetpack?hl=en
> > <http://groups.google.com/group/mozilla-labs-jetpack?hl=en>
>
> Tried that, it's read-only.
I just joined the Google Group. It took me two seconds. It's open to
anyone who wants to join.
Al
Al Billings
> >>> 1) the news group
> >>>http://groups.google.com/group/mozilla-labs-jetpack?hl=en
> >>> <http://groups.google.com/group/mozilla-labs-jetpack?hl=en>
>
> >> Tried that, it's read-only.
> > Check your settings. Here is what I see set up and its set way for
>
> ...
> My apology for be abrupt. I meant: posts to that newsgroup do not create
> dialog.
They do if you speak to the people on the list (not a newsgroup) and
they reply back. That list is the best place to discuss what is going
on with Jetpack, if you are actually curious.
> > Some of the ideas being kicked around would allow for this the way I
> > understand things that would be developed as jetpack modules. But it
> > would mean your going to have to refactor and change code in your addon.
>
> Where is this kicking happening?
Again, I suggest that you join the Jetpack e-mail list.
Al
johnjbarton
> On Feb 12, 1:59 pm, johnjbarton<johnjbar...@johnjbarton.com> wrote:
>
>>>>> 1) the news group
>>>>> http://groups.google.com/group/mozilla-labs-jetpack?hl=en
>>>>> <http://groups.google.com/group/mozilla-labs-jetpack?hl=en>
>>
>>>> Tried that, it's read-only.
>>> Check your settings. Here is what I see set up and its set way for
>>
>> ...
>> My apology for be abrupt. I meant: posts to that newsgroup do not create
>> dialog.
>
> They do if you speak to the people on the list (not a newsgroup) and
> they reply back. That list is the best place to discuss what is going
> on with Jetpack, if you are actually curious.
I'm sorry I don't understand what you are saying. Which list is not a
newgroup?
>
>>> Some of the ideas being kicked around would allow for this the way I
>>> understand things that would be developed as jetpack modules. But it
>>> would mean your going to have to refactor and change code in your addon.
>>
>> Where is this kicking happening?
>
> Again, I suggest that you join the Jetpack e-mail list.
Which list? I've been following the group listed above. I'm yet to see
any discussion of architecture or migration. Mostly the discussion is
about API (which seems premature) and versions of jetpack that are defunct.
Just to reiterate I think jetpack is a fabulous concept and has cool
ideas. But it's not remotely suitable for the future of extensions, the
subject here.
jjb
>
> Al
Philip Chee
Some of us are sceptical of such promises since these while these are
statements from influential people in the mozilla ecology, nobody has
actually committed to not forcing such a migration, or at least not
making it painful for those people who don't want to migrate.
Phil
--
Philip Chee <phi...@aleytys.pc.my>, <phili...@gmail.com>
http://flashblock.mozdev.org/ http://xsidebar.mozdev.org
Guard us from the she-wolf and the wolf, and guard us from the thief,
oh Night, and so be good for us to pass.
[ ]Know a good chiropractor? My computer has a slipped disk.
* TagZilla 0.066.6
Philip Chee
>> You've already made the decision that current extensions will be
>> obligated to recode to jetpack. Since I don't consider that to be
>> feasible, I'm not very interested in such a migration.
> If the problem is that we have no compatibility layer right now, and
> addons can reach into any part of the platform including:
>
> -areas that are frozen and will remain so
> -areas that have been frozen but we have plans to change
> -areas that are not frozen and were intended to be accesses
>
> If addons want to get out of compatibility hell then a recoding effort
> will be required. The goal is to make this only one recoding effort, or
> the absolute fewest possible as we get to a stable set of APIs that
> provide the abstraction needed to hide the problem listed above in items
> 2 and 3.
>
> The current addons face two tough choices. Try and chase compatibility
> problems as they have for the last 5 years, or switch over to an API
> that hides the details of the evolving platform. If you have any ways
> around these choices lets here about them.
I understand the need for a stable API, but do you really want to end up
like IBM with the latest mainframes capable of running the oldest S360
programs via several layers of VMs?
Also currently Flashblock[1] supports Firefox 1.5 all the way to 3.7a1.
So while not generally applicable for simple extensions this isn't
necessarily that difficult.
[1] I also have a parallel version of Flashblock that supports Firefox
all the way back to 1.0.7 on my website.
Philip Chee
> I'm sorry I don't understand what you are saying. Which list is not a
> newgroup?
Apparently the Jetpack developers consider it unnecessary to talk to
riff-raff extension developers who inhabit newsgroups.
johnjbarton
> The current addons face two tough choices. Try and chase compatibility
> problems as they have for the last 5 years, or switch over to an API
> that hides the details of the evolving platform. If you have any ways
> around these choices lets here about them.
>
I think a lot could be gained by explaining what you mean by "switch
over to an API". I have 40,000 lines of code. What percent will you ask
me to change?
jjb
Gijs Kruitbosch
Any reason this group doesn't seem to be on the newsgroup server, where I follow
all my other mozilla lists/groups?
~ Gijs
Shawn Wilsher
> Some of us are sceptical of such promises since these while these are
> statements from influential people in the mozilla ecology, nobody has
> actually committed to not forcing such a migration, or at least not
> making it painful for those people who don't want to migrate.
>
you are taking the pessimistic route!
Cheers,
Shawn
Chris Ilias
> Any reason this group doesn't seem to be on the newsgroup server, where
> I follow all my other mozilla lists/groups?
The Google Groups <-> NNTP gateway wasn't working at the time labs
wanted their newsgroups set up.
See <https://bugzilla.mozilla.org/show_bug.cgi?id=480543>.
Gijs Kruitbosch
You're using past tense here - am I to understand it is working again? What's
preventing the mirroring from happening now anyway? I would have commented on
the bug but the last few comments indicate that it is not the right bug to do
that in, yet annoyingly fail to mention which bugs I *should* be looking at...
~ Gijs
Philip Chee
That was the excuse then. What is the excuse *now*?
Phil
--
Philip Chee <phi...@aleytys.pc.my>, <phili...@gmail.com>
http://flashblock.mozdev.org/ http://xsidebar.mozdev.org
Guard us from the she-wolf and the wolf, and guard us from the thief,
oh Night, and so be good for us to pass.
[ ]My software never has bugs. It just develops random features...
* TagZilla 0.066.6
Robert Kaiser
> The current outlook for extensions is bleak. We have heard about two
> decisions made by someone somewhere, one to re-architect XUL
> applications into multiprocess and one to replace the current extension
> system with jetpack.
From all I heard, the second one is just not true. Jetpack will not
replace the current extension mechanism but provide a preferred and
easier-to-use option for the majority of extensions, the more deep-going
ones, of which Firebug is surely one, can still use the "traditional"
full way of doing extensions.
Robert Kaiser
johnjbarton
Robert I hope you will join me in what may be a futile but noble effort
towards clear communications. Please can we call the things that jetpack
enables 'jetpacks' as a type of "add-on" and leave "extension" to mean
the type of add-on used by Firebug, AdBlock, NoScript and so on?
We can have four kinds of add-ons, extensions, jetpacks, themes, and
Personas. We can have more kinds of add-ons. It's a simple step towards
clearer communications.
So I agree that Jetpack will not replace the extension mechanism; it
seeks to provide an easier-to-use approach to create add-ons.
Or so I hope. But that is exactly why I posted here: the future of
extensions is not being discussed outside of Jetpack. If you cut down a
tree or just stop watering it until it falls on its own, it's still a
tree I don't want to climb on.
>
> Robert Kaiser
chris hofmann
I'm not going to ask you to change anything if you don't want to.
Here is what I'd ask you if you want to engage in helping to try and
improve the current extension and jetpack architecture.
As mentioned over in the jetpack google group, I'd ask you to think
about the idea of refactoring the code within Firebug and other addons
to create a library that handles the interactions with gecko and hides
the details of implementation. Think about if thats possible, and then
think about if that would gain a better level of compatibility and
maintainability of Firebug and these current addons. Think about what
the cost of that work might might be, and if the cost is worth the
possible benefit gained buy not having to deal with compatibility
problems at each major release. Run some experiments about what the
refactoring work might look like. See if you can re-use some of the
other jetpack libraries as they get created over the next few months.
Then share lessons learned.
-chofmann
> jjb
johnjbarton
Well I've already tried to share my experience with maintaining Firebug.
I'll say it again: it's not about API compatibility. I can't even
remember a significant API change. It's just not important: mozilla does
a wonderful job of creating a stable API for extensions.
So there is no benefit to be gained by refactoring for that goal.
The kinds of problems we face when dealing with new versions of Firefox
are changes in semantics, mostly driven by platform bug fixes. The
platform is very large and it has a very large number of bugs (it is
also one of the least buggy large systems). As the use pattern of the
platform changes due to performance tuning (eg Ts work), or new
implementations (eg HTML5), or security issues (eg wrappers), these bugs
are uncovered and fixed. But the fix introduces changes that are not
detected by mozilla's automatic testing. The changes are detected when
we run because we exercise the platform in ways not addressed by the
automatic testing.
The problem is further compounded by the development cycle. All through
the alpha and beta phase the bug fixes that cause us problems are being
revised as those problems (typically uncovered by others but some by us)
arise. So only at the very end of the beta can we see that we are on
track to success.
I don't know of any refactoring or shim API solution to this problem.
That is why I don't buy the jetpack compatibility story.
You may have experience that is different. As far as I know, there is
not data on what causes extensions to fail compatibility. So we are left
to argue and I have only my experience to defend.
jjb
Asa Dotzler
> Robert I hope you will join me in what may be a futile but noble effort
> towards clear communications. Please can we call the things that jetpack
> enables 'jetpacks' as a type of "add-on" and leave "extension" to mean
> the type of add-on used by Firebug, AdBlock, NoScript and so on?
>
> We can have four kinds of add-ons, extensions, jetpacks, themes, and
> Personas. We can have more kinds of add-ons. It's a simple step towards
> clearer communications.
If you really want clear communications then it's 5 kinds of add-ons.
Plug-ins, of the NPAPI type are add-ons as well. I'd love there to be 6
or 7 kinds of add-ons in the not too distant future if greasemonkey
style scripts get added and stylish style css gets added to the add-ons
ecosystem.
- A
chris hofmann
Right. The problem space for testing is that any addon can reach into
gecko in any of a variety of ways and become dependent on symantics.
If we can consolidate they general ways addons reach into gecko,
develop a standard shim layer that all addons use and have good test
cases that exercise this shim layer there is hope for adding this to the
standard test suite to gecko testing on each build.
Then we know will when things break earlier, and the fix will be in one
place, not a broadcast to 10,000 addon developer to check their code
and all start to make suggested hacks to accomodate the new semantics.
> The problem is further compounded by the development cycle. All
> through the alpha and beta phase the bug fixes that cause us problems
> are being revised as those problems (typically uncovered by others but
> some by us) arise. So only at the very end of the beta can we see that
> we are on track to success.
>
> I don't know of any refactoring or shim API solution to this problem.
> That is why I don't buy the jetpack compatibility story.
>
agree that the problem of accounting for changes in the platform don't
go away. they just get consolidated into the abstraction layer, so we
can learn about the impact of changes earlier, and make ajustments to
the changes in one place and on tens, hundereds, or thousands of addons.
-chofmann
> You may have experience that is different. As far as I know, there is
> not data on what causes extensions to fail compatibility. So we are
> left to argue and I have only my experience to defend.
>
> jjb
Chris Ilias
> On Sat, 13 Feb 2010 19:48:33 -0500, Chris Ilias wrote:
>
>> Preface: I can only speak for myself here.
>>
>> My guess is that once the discussion groups were created on Google,
>> opened to the public, and linked to from
>> <https://mozillalabs.com/discussions/>, the need to make them accessible
>> via NNTP just hasn't been on anyone's mind. So to answer your question,
>> as far as I know, nothing is preventing that from happening now.
>>
>> Of course, the Labs folks may not want to move the groups, now that they
>> are already created. I cannot speak for them.
>
> Nobody said anything about moving, only about getting the gateway
> working. Once this is done, nobody will have to move anywhere.
Maybe there is a misunderstanding. There are two types of Google Groups:
1. a web-based gateway/archive of newsgroups, which supports NNTP feeds
to/from news servers.
2. their own discussion group system, which does not support NNTP.
More info:
<http://groups.google.com/support/bin/answer.py?hl=en&answer=46461>
Mozilla newsgroups/lists use #1. The labs groups are #2 (because they
couldn't get #1 to work at the time).
timeless
https://bugzilla.mozilla.org/show_bug.cgi?id=480543 which died a death
of sorts. https://bugzilla.mozilla.org/show_bug.cgi?id=497945 asks to
remove all traces of it.
it'd be better if we could find a live contact at google to fix this.... :(
Gervase Markham
> On 13/02/2010 10:58 AM, Chris Ilias wrote:
>> On 10-02-13 3:43 AM, Gijs Kruitbosch wrote:
>>> Any reason this group doesn't seem to be on the newsgroup server, where
>>> I follow all my other mozilla lists/groups?
>>
>> The Google Groups <-> NNTP gateway wasn't working at the time labs
>> wanted their newsgroups set up.
>> See <https://bugzilla.mozilla.org/show_bug.cgi?id=480543>.
>
> You're using past tense here - am I to understand it is working again?
It is.
> What's preventing the mirroring from happening now anyway?
Because to get that working, the relevant Google Group has to be created
as part of the process of setting up the three linked systems. My
understanding is that it's not possible to bind an arbitrary Google
Group into the system later (Chris I's post seems to support this).
Bottom line: Google failed, Labs were impatient, it's hard to fix it now.
We've looked several times at whether there are better ways of doing our
discussions system while still meeting all the requirements, but have
not found any. If anyone knows of a web UI to mailing lists or news
which is as easy to use as Google Groups, we would be happy to install
it and use it as the "web" piece of the discussion. Then, we would get
much faster turnaround and much more control.
Gerv
Mike Beltzner
> Bottom line: Google failed, Labs were impatient, it's hard to fix it now.
Bottom-bottom line: the overhead of supporting NNTP here isn't worth the benefit. It's not onerous to subscribe as a mailing list or participate as a web forum. Many other projects use this system without NNTP. I am sure this will annoy some people, I don't know if the relevant stakeholders and project drivers need to care about that.
The system is open and inviting, but not ubiquitously available. People expecting to participate using lettermail or telegram will be similarly disappointed, I fear.
cheers,
mike
Robert Kaiser
> On 2010-02-15, at 6:55 AM, Gervase Markham wrote:
>
>> Bottom line: Google failed, Labs were impatient, it's hard to fix it now.
>
> Bottom-bottom line: the overhead of supporting NNTP here isn't worth the benefit.
You're drawing conclusions in a very strange way.
Robert Kaiser
Shawn Wilsher
> You're drawing conclusions in a very strange way.
discussions is a cost that is completely worthwhile to get NNTP, correct?
Cheers,
Shawn
Philip Chee
I think what KaiRo means that just because Google can't do it, that
doesn't mean that we can't do something about it ourselves. For example
mozilla could set up their own private mail-to-news gateway for this
particular mailing list. I think that there should be some suitable off
the shelve open source software (gmane?) that could be used.
Mike Beltzner
> I think that there should be some suitable off the shelf open source software (gmane?) that could be used.
I don't think GMane allows posting to the list from the web, does it?
BTW, this thread has meandered off topic. Further discussion of this particular issue should be taken to, ironically, one of the Labs discussion groups.
cheers,
mike
Gervase Markham
> Bottom-bottom line: the overhead of supporting NNTP here isn't worth
> the benefit.
> It's not onerous to subscribe as a mailing list or
> participate as a web forum.
Well, it is, actually.
Workflow when subscribing via NNTP (in Thunderbird):
- Right click news server, click "Subscribe..."
- Find item in list
- Click checkbox
- Click OK
Workflow when subscribing via email:
- Send email to subscription address
- Wait for confirmation email (can take time if you have greylisting)
- Reply to confirmation email
- Create a folder for posts to go in
- Tools | Message Filters - set up yet another filter
And even then, threading and marking threads as read isn't nearly as
good as the News version.
As for the Google Groups web UI, it doesn't even seem to have the
concept of marking messages as read!
People who prefer NNTP aren't just old-school reactionaries, you know.
It's a decision taken on technical grounds. Google Groups is a
best-in-class web UI for discussions, and it's still not as good as a
native news client. Most blogs and things like PHP-BB (ugh!) don't even
come within a country mile. The fact that people use them is a tribute
to the human desire to communicate even when obstacles are placed in the
way, not an endorsement.
> Many other projects use this system
> without NNTP. I am sure this will annoy some people, I don't know if
> the relevant stakeholders and project drivers need to care about
> that.
Why don't we use it without the web UI? That would solve the problem
with coordinating with Google Groups. I'm sure that'll annoy some people
too, but I don't know if the relevant stakeholders etc. etc.
It would be useful if we had some relevant usage percentages, so we can
see how many people either of these changes would actually annoy. I will
try and come up with some.
> BTW, this thread has meandered off topic. Further discussion of this
> particular issue should be taken to, ironically, one of the Labs
> discussion groups.
Sure. Which one?
Gerv
Robert Kaiser
> People who prefer NNTP aren't just old-school reactionaries, you know.
> It's a decision taken on technical grounds. Google Groups is a
> best-in-class web UI for discussions, and it's still not as good as a
> native news client. Most blogs and things like PHP-BB (ugh!) don't even
> come within a country mile. The fact that people use them is a tribute
> to the human desire to communicate even when obstacles are placed in the
> way, not an endorsement.
Well put, couldn't say it in a better way!
Robert Kaiser
Mike Beltzner
> People who prefer NNTP aren't just old-school reactionaries, you know.
Uhm, your words, not mine. What I claimed was that people who currently use NNTP can get almost the exact same experience by signing up for an email list and setting up mail filters. Yes, there are more steps involved in the process, but they can achieve the exact same workflow.
> Why don't we use it without the web UI?
I will refer you to the mission of the organization which employes you directly, me indirectly, and is the driving purpose of all who participate in our project.
(Your argument is making an assumption that the benefit of supporting the NNTP based workflow for the existing community members outweighs the opportunity cost such systems being less visible to potential new community members who are working and living on the web, and may not use client side software for email nor NNTP)
cheers,
mike
David E. Ross
Mailing lists get contaminated with "I'm on vacation" messages.
Mailing lists require the same effort to unsubscribe as to subscribe
(more effort than unsubscribing from a newsgroup).
Mailing lists can more likely than newsgroups involve unwrapped
paragraphs, which result in excessively long lines of text.
--
David E. Ross
<http://www.rossde.com/>.
Anyone who thinks government owns a monopoly on inefficient, obstructive
bureaucracy has obviously never worked for a large corporation. � 1997
Robert Kaiser
> On 2010-02-22, at 6:43 AM, Gervase Markham wrote:
>> Why don't we use it without the web UI?
>
> I will refer you to the mission of the organization which employes you directly, me indirectly, and is the driving purpose of all who participate in our project.
The mission IIRC doesn't state that HTTP/HTML is better than any other
open Internet protocol, and if it does, it's plain wrong.
Robert Kaiser