That's not going to change, and I more fear us changing the way we work in a potentially futile hope to modify the way reporters report on us.
Gregg's a good guy, and while I would have appreciated him mentioning that Schrep explicitly called this a "draft" plan, he's trying to report honestly on what he's observing. I don't think it's a problem at all, and we should continue to educate journalists and observers to the fact that this is how software development works. People propose plans, people discuss them, and figure out if it's the right thing to do. We just do all of that in the open. It's a double whammy - people need to get used to learning how software is made, and the idea that we do it in the open.
Let's work with people like Gregg to help him understand what we're doing, and perhaps encourage him to interact with us here.
----- Original Message ----- From: dev-planning-boun...@lists.mozilla.org
<dev-planning-boun...@lists.mozilla.org> To: dev-plann...@lists.mozilla.org <dev-plann...@lists.mozilla.org> Sent: Wed May 21 14:24:01 2008 Subject: Re: What's next after Firefox 3 and Gecko 1.9?
On May 19, 2:38 pm, schrep <sch...@mozilla.com> wrote: > There were a number of features that we held back from Firefox 3 ... > These > include things like XHR
Reporters are watching like a hawk so they can misconstrue whatever people say ;-) _______________________________________________ dev-planning mailing list dev-plann...@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-planning
In addition to choffman's points, we really need to make "workarounds" available to show extension developers how to rewrite the old code to the new code. We have had a decent set of good examples in the 1.9 timeframe, but there are times where changes are made and no background is given for how to convert existing code. This slows things down.
On May 19, 9:58 pm, Boris Zbarsky <bzbar...@mit.edu> wrote:
> chris hofmann wrote: > > The best thing that could be done is to map out *which* APIs might > > change, then do a bit of estimating on what the impact of the changes > > might be on extension compatibility and the back end of the schedule. > > Where is a good area to start mapping out the proposed changes?
> Can we turn that around? Would it be possible, given an interface, to scan AMO > for binary extensions that use that interface in their binary blobs?
Sure, I have routinely asked AMO to given me a grep of addons using certain interfaces. They are usually very prompt with the information, especially if used to help keep extensions functional.
> > The other thing is that if we are going to change APIs, we need to get > > this work done early, and enforce some early API freeze dates.
> The problem is that API changes are not the end in and of themselves, usually. > They are often needed, for our core "internal" APIs to address other issues that > come up. No one is suggesting changing APIs for the fun of it, I don't think.
> For example, note that if a blocker issue comes up in RC1 right now that can be > most easily fixed by changing nsIContent we would change nsIContent before we > ship final. The question is whether 1.9.1 should be held to a higher bar than > this (as 1.8.1 was).
If a blocker comes up in RC1 and we fix it by changing nsIContent in such a way that breaks extensions, then I think we have done a bad thing. At this late stage, we certainly should be favor non-ideal ways (short-lived private interfaces, maybe) over outright breakage. If we do make breaking changes (for extensions) we should be moving into some tactical mode of extension developer outreach - before the code lands.
We don't get a bad rap from extension developers for no good reason.
Mark Finkle wrote: >> Can we turn that around? Would it be possible, given an interface, to scan AMO >> for binary extensions that use that interface in their binary blobs?
> Sure, I have routinely asked AMO to given me a grep of addons using > certain interfaces. They are usually very prompt with the information, > especially if used to help keep extensions functional.
I'm not sure a grep would catch binary blobs using the interface. Those are the things we're worrying about here, not JS using the interface.
> If a blocker comes up in RC1 and we fix it by changing nsIContent in > such a way that breaks extensions, then I think we have done a bad > thing.
Given that extensions shouldn't be using nsIContent to start with, really, I don't think we are.
> At this late stage, we certainly should be favor non-ideal ways > (short-lived private interfaces, maybe) over outright breakage.
The question is whether adding 4 bytes to every single DOM node is worth avoiding possibly breaking binary blob extensions that are using internal APIs that we clearly say are very unstable. On the 1.8 branch, the official answer to that was "yes", but it might have been the wrong tradeoff. I certainly think it's the wrong tradeoff before we ship.
> If we do make breaking changes (for extensions) we should be moving into > some tactical mode of extension developer outreach - before the code > lands.
_Any_ change to _any_ interface is a breaking change for binary blob extensions. Again, this is why we didn't make them on the 1.8 branch. I fully agree on outreach for API changes at this late date or on the branch in general.
> We don't get a bad rap from extension developers for no good reason.
A bad rap from extension developers who are using internal interfaces we tell them not to use?
Would we care about a bad rap from extension developers that binary-patched libxul and complained when the library bit pattern changed in a security update?
Boris Zbarsky wrote: > _Any_ change to _any_ interface is a breaking change for binary blob > extensions.
Could you elaborate a bit, why this happens? Because IID should change, whenever interface changes, right?
IIUC, if an interface changes that an extension *implements*, the extension will crash. If an extension only *calls* some methods/attributes of an interface, and the order of methods/attributes changes in the interface, or methods/attributes are removed from the interface, or methods/attributes are inserted into the interface anywhere but at the end, the extension will crash. However, if method/attributes are inserted at the end of the interface, everything should be fine.
The last case is an exception to the quoted rule, right?
On Sun, May 25, 2008 at 12:08 AM, Boris Zbarsky <bzbar...@mit.edu> wrote: > A bad rap from extension developers who are using internal interfaces we tell > them not to use?
And for which we provide supported alternatives for their use cases, or not?
> Would we care about a bad rap from extension developers that binary-patched > libxul and complained when the library bit pattern changed in a security update?
> If we wouldn't, where is the line drawn and why?
They're different to me because extension authors are likely to be copying the use-of-internal-interface pattern from our code, but are unlikely to be copying binary patching from anywhere reputable. (We have been concerned with getting a bad rap in the past about similarly fragile behaviours.)
I don't know what you mean by "internal", exactly, or why we would have internal interfaces that were accessible at all by textual name from other code without explicit opt-in (by which I mean defining something like MOZILLA_INTERNAL_API, not "including the wrong header file"), but there are many use cases that are simply not workable without use of non-frozen interfaces at the least. nsIContent -- beyond the IID identity, I guess -- is protected MOZILLA_INTERNAL_API, but a file like that in a public/ directory with commented and useful-sounding methods seems like it's basically baiting you to set MOZILLA_INTERNAL_API. (If you're finding things like SetAttr or GetText via lxr, you won't even see the tiny and cryptic comment at the top of the class declaration.) Things in our own extensions/ directory (xforms, TAF, spellcheck) use nsIContent quite liberally, to say nothing of SVG and editor and...
Given that there is precious little documentation explaining the right way to interact with our content model (especially if performance is a concern), I think a good chunk of the burden for extension developers using Impure Interfaces falls to us as well. If we actually told people what to do instead, from nsIContent.h or a page liberally linked from there, I would feel better about giving developers a hard time about using it, especially given some time after that documentation was available for other right-thinking examples to build up. Right now, I think the story is "use the DOM interfaces", which means figuring out what sort of node .textContent is on, getting a bunch of QIs right, and being totally bereft of examples to follow to see if you got the XPCOM arcana correct. "Go read the W3C specification text" is pretty unsatisfying! (If the DOM interfaces are so great, why doesn't more of our own code use them?)
Nobody has time to write alternative-to-internals docs, I'm sure I will hear, and I expect that there will be a number of defensive reactions to what I write here, but those decisions are economics. Right now we're saying that there are more important things than helping people get weaned off of private interfaces, by making the Right Thing also the Easier To Figure Out Thing. That might well be the right decision in terms of resources, but it means that we have to bear the cost of well-meaning and valuable extension developers getting wed to the capabilities of nsIContent and other such friends.
Sergey Yanovich wrote: > Could you elaborate a bit, why this happens? Because IID should change, > whenever interface changes, right?
That's correct. Which means the extension that uses that interface is likely to stop working, if it gets pointers to that interface via QI. If it gets them from other interfaces, it would get a pointer to a vtable that differs from what it expects.
> However, if method/attributes are inserted at the end of the interface, everything > should be fine.
If the extension is not getting the interface via QI, yes.
> The last case is an exception to the quoted rule, right?
Mike Shaver wrote: > And for which we provide supported alternatives for their use cases, or not?
That's a good question. I'd love to provide different interfaces for their use cases; my attempts to gather information about such use cases in the past when people posted in newsgroups about their nsIContent, etc. use have failed.
> They're different to me because extension authors are likely to be > copying the use-of-internal-interface pattern from our code, but are > unlikely to be copying binary patching from anywhere reputable.
I buy this, ok. I admit the comparison was silly.
For what it's worth, I agree that the bar for nsIContent changes after ship (if any) should be very high. I'm just not convinced that it should be quite that high before ship, even at the point where we are now. But I might be wrong on this depending on what we've been communicating to extension developers...
> I don't know what you mean by "internal", exactly
I'm mostly thinking our main layout/content data representation: nsINode, nsIContent, nsIFrame. Those are the ones that would be most painful to never ever ever change.
> nsIContent -- beyond the IID identity, I guess -- is protected MOZILLA_INTERNAL_API, > but a file like that in a public/ directory with commented and > useful-sounding methods seems like it's basically baiting you to set > MOZILLA_INTERNAL_API.
Yeah, that's a bad deal. :(
> Things in our own extensions/ directory (xforms, TAF, spellcheck)
Yeah. Part of the reason there is performance, certainly for TAF and spellcheck.... Perhaps in the new mmgc world using nsIDOMNode and company won't be quite as painful in terms of incessant refcounting. But given the way the DOM tosses things on lots and lots of interfaces, there could still be QI costs. :(
> Given that there is precious little documentation explaining the right > way to interact with our content model (especially if performance is a > concern)
More importantly, the lack of a right way to interact with our content model if performance is a concern.
> I think a good chunk of the burden for extension developers
> using Impure Interfaces falls to us as well.
Agreed.
> Right now, I think the story is "use the DOM interfaces", which > means figuring out what sort of node .textContent is on, getting a > bunch of QIs right, and being totally bereft of examples to follow to > see if you got the XPCOM arcana correct.
That's a pretty good summary, yes.
> Nobody has time to write alternative-to-internals docs
The docs would be less of a problem if we had an actual alternative. What we _really_ need here time-investment wise is either some API design or making nsIDOM* suck less or both.
On Sun, May 25, 2008 at 11:07 AM, Boris Zbarsky <bzbar...@mit.edu> wrote: > The docs would be less of a problem if we had an actual alternative. What we > _really_ need here time-investment wise is either some API design or making > nsIDOM* suck less or both.
I have a very strong preference for the latter or something close to it, since it would also improve content performance.
(Something close to it might be "replace nsIDOM* and make content use that as well", for example.)
Boris Zbarsky wrote: > Yeah. Part of the reason there is performance, certainly for TAF and > spellcheck.... Perhaps in the new mmgc world using nsIDOMNode and > company won't be quite as painful in terms of incessant refcounting. > But given the way the DOM tosses things on lots and lots of interfaces, > there could still be QI costs. :(
Coupla random notes, not really disagreeing with anyone:
* This whole discussion becomes increasingly irrelevant for moz2: the JS APIs will be the canonical/stable ones, and internal/binary APIs may change as needed
* We can certainly condense some of the DOM APIs: there's no need to keep separate nsIDOMX, nsIDOM3X, nsIDOMXInternal interfaces that have evolved due to early freezing etc.
* I do think we should be tackling the problem of being able to implement TAF and spellcheck from JS in ways that are roughly equivalent to binary performance: it can be done with a better crossing layer and tracing.
Mike Shaver wrote: > On Sun, May 25, 2008 at 11:07 AM, Boris Zbarsky <bzbar...@mit.edu> wrote: >> The docs would be less of a problem if we had an actual alternative. What we >> _really_ need here time-investment wise is either some API design or making >> nsIDOM* suck less or both.
> I have a very strong preference for the latter or something close to > it, since it would also improve content performance.
Benjamin Smedberg wrote: > * This whole discussion becomes increasingly irrelevant for moz2: the JS > APIs will be the canonical/stable ones, and internal/binary APIs may > change as needed
Sure, but the question on the table right now is 1.9.1 (and 1.9.0), I think.
> * I do think we should be tackling the problem of being able to > implement TAF and spellcheck from JS in ways that are roughly equivalent > to binary performance: it can be done with a better crossing layer and > tracing.
Right now, even implementing them in C++ on top of nsIDOM* would come nowhere close to using nsIContent performance-wise. The better crossing layer there might actually help over raw nsIDOM* use from C++ (reduce QIs). And of course reducing the refcounting and virtual function calls and out params etc involved would all help...
On May 25, 12:08 am, Boris Zbarsky <bzbar...@mit.edu> wrote:
> Mark Finkle wrote: > > If a blocker comes up in RC1 and we fix it by changing nsIContent in > > such a way that breaks extensions, then I think we have done a bad > > thing.
> Given that extensions shouldn't be using nsIContent to start with, really, I > don't think we are.
> > We don't get a bad rap from extension developers for no good reason.
> A bad rap from extension developers who are using internal interfaces we tell > them not to use?
I was speaking in a more general sense (applying to any externally, usable interface), using your specific nsIContent case as an example.
Mark Finkle wrote: > I was speaking in a more general sense (applying to any externally, > usable interface), using your specific nsIContent case as an example.
It's a bad example to generalize from, and the one most relevant to sicking's original question.
> There have been several discussions of 1.9.1/Moz2 and future product > releases here > (http://groups.google.com/group/mozilla.dev.planning/browse_frm/thread......) > and it has been discussed many times in the Mozilla 2 meetings. Not > everyone could make those meetings but more importantly not everyone was > aware we would be discussing 1.9.1/moz2 there.
> In order to drive us closer to conclusion I wanted to consolidate my > understanding of the current plan in *early* draft form below. I > propose we iterate on this here and take a final form to the > wiki's/blogs for wider distribution.
> So please edit, add questions, to the draft below...
> Best,
> Schrep
> *** DRAFT PLAN **** > *******************
> Product Releases > ----------------
> Firefox 2.0.0.x and 3.0.x:
> We'll continue the maintenance schedule we set with Firefox 1.5 - namely > doing scheduled maintenance releases of Firefox 3.0.x and Firefox > 2.0.0.x every 6-8 weeks. These releases will focus on security and > stability improvements and cannot add new features, change UX, or break > extensions unless it is required for security purposes or is otherwise > critical. Since Firefox 3.1 is coming out so quickly after 3.0 I > expect the size of these maintenance releases to be smaller than they > have been for the 2.0.0.x series. Support releases for Firefox 2.0.0.x > will terminate at the latest approximately 6 months after the shipment > of Firefox 3. This coincides with the approximate ship date of > Firefox 3.1.
> Firefox 3.1:
> There were a number of features that we held back from Firefox 3 because > they weren't quite ready - but they were nearly complete. These > include things like XHR, native JSON DOM bindings, ongoing performance > tuning, awesomebar++, better system integration, etc. This along with > the overall quality of Gecko 1.9 as a basis for mobile and the desire to > get new platform features out to web developers sooner has lead to us > want to do a second release of Firefox this year. This release would > be date-driven and targeted at the end of 2008. Any features not ready > in time will move to the next major release. This is currently planned > to be based on Gecko 1.9.1 - but if there are solid technical reasons > for breaking frozen APIs we will bump the version number to Mozilla2.
> Firefox Mobile:
> There are already devices shipping with early versions of Gecko 1.9 at > the core. More are coming soon and we'll be releasing milestones of > full branded versions of Firefox (with XUL and the Firefox team taking a > lead in the user experience) later this year. This lines up well with > Firefox 3.1 and a synchronized release schedule will make everything run > more smoothly.
> Firefox 4:
> Firefox 4 will incorporate some of the more aggressive platform > improvements in Mozilla2. It is far too early to set a shipping date > but an initial target would be sometime in late 2009. Mozilla2 work has > been underway for > 8 months
> Platform Releases > -----------------
> Gecko 1.9.0.x:
> Release date: By end of June 2008 > Status: Stable > Accepted Changes: Security, stability, performance, minor enhancements > that do not change *any* exposed APIs. All changes must pass all > regression tests and not regress performance. > Development Tree: CVS Trunk > Bugzilla Flags: blocking1.9.0.x > Planning Center:
> Gecko 1.9.1:
> Release date: Beta stable summer 2008, production stable end of 2008 > Status: In development > Accepted Changes: Anything that doesn't break frozen API's. Passing > unit tests and proof of no negative impact on perf from Talos required > before check-in > Development Tree: Hg mozilla-central - will move to a branch before end > of summer 2008 > Bugzilla Flags: blocking1.9.1 > Planning Center:
> Mozilla2:
> Release date: Beta stable mid 2009 > Status: In development > Accepted Changes: Anything that doesn't regress functionality or performance > Development Tree: Hg mozilla-central > Bugzilla Flags: ? > Planning Center:http://wiki.mozilla.org/Mozilla_2
> Q&A > ------
> Q: I'm running a project based on Gecko and am confused as to weather to > ship on 1.9.0.x, 1.9.1, or Mozilla2?
> A: If you are shipping before Nov/Dec 2008 we recommend you ship on > Gecko 1.9.0.x since it is the stable release. If your product is > shipping after Dec 2008 we'd recommend you use Gecko 1.9.1.x since it > will be stable by then. If you are shipping later you may want to > consider Mozilla2
> Q: Will Firefox 3.1 ship on 1.9.1 or Mozilla2?
> A: We will start with 1.9.1 but if there is a compelling technical > reason to break frozen APIs the drivers and module owners may decide to > do so. If we break frozen APIs we will call it Gecko 2.0 and give fair > notice.
> Q: .... please add common questions here..
Regarding whether or not Fx3.1 will ship on 1.9.1 or 2.0--I think the Mozilla2 name is psychologically significant and should not be used even if there's a valid reason to break APIs on what would otherwise by 1.9.1.
Mozilla2 has a broader significance in terms of the direction and revitalization of Gecko (as was outlined by Brendan Eich almost two years ago (wow time flies)).
If 1.9.1 needs to break APIs, I think it would be a better idea to call it 1.10.0, even though it's somewhat lame to have point numbers reach 10+. Since Fx3.1 is a *minor release* and the revisions of Gecko (even if they do break some APIs) will still be comparatively minor, going to 1.10.0 will make more psychological sense than going to 2.0.
