1.9 trunk / 1.8 branch, or Firefox 2 / 3, tree management plan

1 view
Skip to first unread message

Brendan Eich

unread,
Dec 12, 2005, 9:04:19 PM12/12/05
to bon...@mozilla.org, dri...@mozilla.org
The proposed plan for handling the trunk and branch over the next year
is at http://wiki.mozilla.org/Global:1.9_Trunk_1.8_Branch_Plan. There's
a FAQ at the bottom:
http://wiki.mozilla.org/index.php?title=Global:1.9_Trunk_1.8_Branch_Plan#A_Dialog.2C_or_FAQ.


I've set followup-to: mozilla.builds to try to get the benefit of a
single newsgroup with good signal to noise, but if people reply-all and
cross-post, it won't be the end of the world.

Comments welcome.

/be

Justin Wood (Callek)

unread,
Dec 13, 2005, 12:09:02 AM12/13/05
to

Thanks for the heads up, this addresses all my initial concerns after
reading the blog entry about FF2 being off 1.8 branch.

~Justin Wood (Callek)

Robert Kaiser

unread,
Dec 13, 2005, 8:12:33 AM12/13/05
to
Brendan Eich schrieb:

> The proposed plan for handling the trunk and branch over the next year
> is at http://wiki.mozilla.org/Global:1.9_Trunk_1.8_Branch_Plan. There's
> a FAQ at the bottom:
> http://wiki.mozilla.org/index.php?title=Global:1.9_Trunk_1.8_Branch_Plan#A_Dialog.2C_or_FAQ.

Two questions:
1) What's the tag for the 1.8.0.x branch?
2) Could stuff like SeaMonkey 1.0 (Beta + Final) get released from
1.8.0.x branch (with security releases coming off there later as well,
if needed) with still having SeaMonkey Council do approvals on
SeaMonkey-only code?

Robert Kaiser

Message has been deleted

Brendan Eich

unread,
Dec 13, 2005, 1:57:20 PM12/13/05
to
Robert Kaiser wrote:
> Brendan Eich schrieb:
>
>> The proposed plan for handling the trunk and branch over the next year
>> is at http://wiki.mozilla.org/Global:1.9_Trunk_1.8_Branch_Plan.
>> There's a FAQ at the bottom:
>> http://wiki.mozilla.org/index.php?title=Global:1.9_Trunk_1.8_Branch_Plan#A_Dialog.2C_or_FAQ.
>
>
>
> Two questions:
> 1) What's the tag for the 1.8.0.x branch?


MOZILLA_1_8_0_BRANCH, of course (our major branches have a rationalized
name scheme that is over seven years old). Nag/reminder: don't touch
this branch without approval.


> 2) Could stuff like SeaMonkey 1.0 (Beta + Final) get released from
> 1.8.0.x branch (with security releases coming off there later as well,
> if needed) with still having SeaMonkey Council do approvals on
> SeaMonkey-only code?


Mail drivers. I'm ok with it so long as SeaMonkey-only is well-defined.
There should be no new free lunches expected from Chase or other build
folks, however.

/be

Brendan Eich

unread,
Dec 13, 2005, 2:00:25 PM12/13/05
to Peter Weilbacher
Peter Weilbacher wrote:

> On Tue, 13 Dec 2005 02:04:19 UTC, Brendan Eich wrote:
>
>
>>The proposed plan for handling the trunk and branch over the next year
>>is at http://wiki.mozilla.org/Global:1.9_Trunk_1.8_Branch_Plan. There's
>>a FAQ at the bottom:
>>http://wiki.mozilla.org/index.php?title=Global:1.9_Trunk_1.8_Branch_Plan#A_Dialog.2C_or_FAQ.
>
>
> Thanks, that makes a lot of sense to me.
>
> Two questions from me, too:
> 1. What do I do if I want a patch to land in 1.8 but it is not a
> crash/leak/dataloss kind of problem. Will there be an approval 1.8.1
> flag for attachments soon?

There should be, if not already, but:

> 1.a Or should I continue to abuse the blocking1.8.1 flag of the bug?


That's no abuse. You need to get the *bug approved* before you should
ask for *patch approval* (but you may patch before either step! Having
a patch in hand is a big plus for getting approval).


> 1.b Is there a Bugzilla/Webtool way to ensure that a bug that is not
> urgent enough for 1.8.0.1 doesn't get forgotten until 1.8.0.1 is out? Or
> do I have to keep my own todo list for this?


Anything approved for 1.8.0.1 should be approved for 1.8.1 too, unless
it is some kind of short term hack-fix. In the past we've managed this
by request both approvals in the common case. If that's too onerous,
I'd be surprised. It gives the queryability you seek.


> 2. "We will extend CVS commitinfo and bonsai to automate synchronization
> of files between trunk and the 1.8 branch"
> Hmm, I can't really say that I understand this sentence. Will CVS
> commits within e.g. xpfe and browser automatically applied to 1.8 if
> checked into trunk and vice versa?


Only to those xpfe directories used by Firefox or Thunderbird. We need
to sort out the details of this auto-sync'ing, so wait a few days and I
will have more to say.

/be

Message has been deleted

Justin Wood (Callek)

unread,
Dec 13, 2005, 11:08:52 PM12/13/05
to
Brendan Eich wrote:

> Peter Weilbacher wrote:
>> 2. "We will extend CVS commitinfo and bonsai to automate synchronization
>> of files between trunk and the 1.8 branch"
>> Hmm, I can't really say that I understand this sentence. Will CVS
>> commits within e.g. xpfe and browser automatically applied to 1.8 if
>> checked into trunk and vice versa?
>
>
> Only to those xpfe directories used by Firefox or Thunderbird. We need
> to sort out the details of this auto-sync'ing, so wait a few days and I
> will have more to say.


SeaMonkey Council may want/desire the syncing as well, though I am
unsure how much work that entails, or if they would actually even want
it. ;-)

~Justin Wood (Callek)

Brendan Eich

unread,
Dec 16, 2005, 8:57:31 PM12/16/05
to
Brendan Eich wrote:
> The proposed plan for handling the trunk and branch over the next year
> is at http://wiki.mozilla.org/Global:1.9_Trunk_1.8_Branch_Plan.


http://wiki.mozilla.org/Global:1.9_Trunk_1.8_Branch_Plan has been
updated to include a branching diagram:
http://wiki.mozilla.org/Global:1.9_Trunk_1.8_Branch_Plan#Branching_Diagram.

Myk is working on the CVS tooling, based on past work from shaver and
others. More next week, when we know more.

/be

Boris Zbarsky

unread,
Dec 23, 2005, 2:19:59 PM12/23/05
to
Brendan Eich wrote:
> The proposed plan for handling the trunk and branch over the next year
> is at http://wiki.mozilla.org/Global:1.9_Trunk_1.8_Branch_Plan. There's
> a FAQ at the bottom:
> http://wiki.mozilla.org/index.php?title=Global:1.9_Trunk_1.8_Branch_Plan#A_Dialog.2C_or_FAQ.

I thought the plan was to make no changes (additions only) to core APIs
based on the pain we've felt in the past. That plan seems to have
changed, somehow. What happened?

-Boris

Axel Hecht

unread,
Dec 27, 2005, 11:38:56 AM12/27/05
to
Regarding the approvals, I recall something like a feature-based
approval scheme for the 1.8 branch, is that still valid, or are we
sticking to a patch-based approval scheme?

I'm still blurry about how to cope with the branches on the l10n side.
I'm tempted to drop the trunk alltogether for the time being. I'm not
sure when it should kick back in, though, probably before a fx3 alpha.
But that doesn't appear on the roadmap at all. I'm afraid I need way
more details for a reliable planning.

Is the calendar file on steelgryphon for fx2 somewhat reliable, at least
in terms of the listed events? Then I'd bother whacking up some
l10n-specific deadlines for it.

Axel

Benjamin Smedberg

unread,
Jan 3, 2006, 10:35:15 AM1/3/06
to Axel Hecht, Brendan Eich
Axel Hecht wrote:

> I'm still blurry about how to cope with the branches on the l10n side.
> I'm tempted to drop the trunk alltogether for the time being. I'm not
> sure when it should kick back in, though, probably before a fx3 alpha.
> But that doesn't appear on the roadmap at all. I'm afraid I need way
> more details for a reliable planning.

Why would we drop the trunk l10n? The build machinery is already there, why
not let localizers keep up to date if they wish? It would be nice for me as
we work on xulrunner+firefox to keep l10n repackaging up to date rather than
wait forever and discover problems at the last minute.

There has been unfortunate talk of taking new features on the 1.8.0 branch
that impact l10n, but I don't think that's a good idea: if we leave the l10n
1.8.0 (ff1.5) release tag static we can get localizers to focus on 1.8 and
trunk.

--BDS

Axel Hecht

unread,
Jan 3, 2006, 12:09:42 PM1/3/06
to
Benjamin Smedberg wrote:
> Axel Hecht wrote:
>
>> I'm still blurry about how to cope with the branches on the l10n side.
>> I'm tempted to drop the trunk alltogether for the time being. I'm not
>> sure when it should kick back in, though, probably before a fx3 alpha.
>> But that doesn't appear on the roadmap at all. I'm afraid I need way
>> more details for a reliable planning.
>
> Why would we drop the trunk l10n? The build machinery is already there,
> why not let localizers keep up to date if they wish? It would be nice
> for me as we work on xulrunner+firefox to keep l10n repackaging up to
> date rather than wait forever and discover problems at the last minute.

Right now, we don't have any builds for anything but the 1.8 branch.
Putting a branch into a "do whatever you whish" leaves that branch
(calling trunk a branch here for simplicity) in a completely unmanaged
state. I'm not eager to find out how to get it back to managed.
My biggest concern, though, is that quite a few localizers don't handle
branches and tree rules well. I'd rather kill an open branch than to
hunt down back-outs and post-landing-approvals on a daily basis.

> There has been unfortunate talk of taking new features on the 1.8.0
> branch that impact l10n, but I don't think that's a good idea: if we
> leave the l10n 1.8.0 (ff1.5) release tag static we can get localizers to
> focus on 1.8 and trunk.

Is there more than the "funny" search plugin removal UI there? If so, I
haven't heard about it, which is evil.

Note that we may have to open up the 1.8.0 branch to specific locales
for the more severe cases of bad localizations. It's not clear that we
can push back all of these for half a year. This is supposed to be
controlled and only sparse, but still.

Anyway, I don't think that setting up a branch for 40 locales is the
right thing to test one architecture cycle. I'm all fine if you try to
find one or two localizations that want to help out with tracking
fx+xulrunner, but opening this up to 40 seems to be distracting and
confusing only.

Axel

Benjamin Smedberg

unread,
Jan 3, 2006, 12:35:49 PM1/3/06
to Axel Hecht
Axel Hecht wrote:

> Right now, we don't have any builds for anything but the 1.8 branch.
> Putting a branch into a "do whatever you whish" leaves that branch
> (calling trunk a branch here for simplicity) in a completely unmanaged
> state. I'm not eager to find out how to get it back to managed.

What's wrong with unmanaged? We don't require approval for trunk checkins,
so why don't we just allow localizers to continue daily localization of the
trunk if they want, and not if they don't? I don't understand how continued
trunk l10n could *hurt* anyone.

> Anyway, I don't think that setting up a branch for 40 locales is the
> right thing to test one architecture cycle. I'm all fine if you try to
> find one or two localizations that want to help out with tracking
> fx+xulrunner, but opening this up to 40 seems to be distracting and
> confusing only.

"open up"? The trunk has been open for months; *closing* it would be a
change. Chase turned off the trunk tinderboxen so that the branch boxes
would cycle faster when we were in the middle of the 1.5 release, but those
can (and should) be turned back on with the flip of a switch.

--BDS

Brendan Eich

unread,
Jan 3, 2006, 2:43:43 PM1/3/06
to Boris Zbarsky, Darin Fisher


Bookmarks and history non-frozen APIs are candidates for breakage, given
the wins of the Places work. The benefits outweigh the costs and I
think someone said some of the old APIs are too painful to emulate on
the new back end.

I'm not sure what interfaces will actually be broken, though. Cc'ing
darin, who may be able to direct us to an updated wiki page or a better
venue than n.p.m.builds.

/be

bre...@gmail.com

unread,
Jan 3, 2006, 3:50:15 PM1/3/06
to
To clarify interface compatability for Places in 2.0:

Places will not support RDF, so RDF interfaces to bookmarks and history
will break. We considered writing an RDF wrapper, but it would be
difficult, have terrible performance, and little payoff. There seems to
be an overall trend of decreasing reliance on RDF anyway.

History APIs will be the same (except for RDF), with the addition of a
huge number of new ones.

Bookmark APIs will break, and there hasn't been much effort on
compatibility. The underlying model for bookmarks is changing to more
of a tagging approach where URLs are assigned to one or more folders
rather than having individual independent bookmarks, making
backwards-compatibility non-trivial. Changing over to use the new
bookmarks API should be straightforward.

There will be several new services with no compatabilioty issues.

Boris Zbarsky

unread,
Jan 3, 2006, 4:16:19 PM1/3/06
to Darin Fisher
Brendan Eich wrote:
> Bookmarks and history non-frozen APIs are candidates for breakage, given
> the wins of the Places work. The benefits outweigh the costs and I
> think someone said some of the old APIs are too painful to emulate on
> the new back end.


Does "old APIs" here mean the frozen ones? Because we MUST continue to
support them. That's what it means for them to be frozen and all.

> I'm not sure what interfaces will actually be broken, though.

I've seen at least one patch floating around that changes the current
global history API in an incompatible manner (changes signature of a
method early in the vtable). I haven't had time to look into whether
such a change is really needed yet, but I think we should be very
conservative about taking such changes on branch.

Then again, this is primarily an issue for embeddors, and I guess our
story for embeddors is to use the 1.8.0.x branch?

-Boris

Brett Wilson

unread,
Jan 3, 2006, 5:34:27 PM1/3/06
to
The only things that will definitely be broken by places at this point
are RDF (which is not an interface and therefore not frozen) and the
bookmarks service (which appears to be unfrozen).

Boris Zbarsky

unread,
Jan 3, 2006, 4:30:22 PM1/3/06
to
bre...@gmail.com wrote:
> Bookmark APIs will break

Does that include the XPCOM apis that core calls (and embeddors
implement)? If so, I'm not incredibly happy about breaking them (though
see comments on 1.8.x vs 1.8.0.x in my previous post).

Frankly, I think that designing our core XPCOM apis (to be used by all
bookmark and history implementations built on top of Gecko) around the
particular bookmark and history setup we're doing for Firefox 2.0 is
short-sighted and dangerous. If we feel that the bookmarks and history
impls are not getting enough information from the back end (which seems
to be the issue here), then we should try to get a list of relevant
information that should be passed on (this step is more or less
independent of the Places arch itself, though Places may suggest some
things that should be in the list), then design the APIs around that
(that is, see which information can't be gotten via existing APIs and
write new APIs to provide it). Then do Places on top of the new API.

Designing the API around Places and only Places mostly means that if we
have a better idea a year or two down the line we'll need to make _more_
API changes. And if some embeddor has a better idea, they simply won't
be able to implement it.

Again, I'm viewing all this from a Gecko standpoint. I don't know
enough about the other end of bookmark and history APIs (the ones the
Firefox bookmark and history impls expose to the Firefox UI and Firefox
extensions) to comment on them intelligently. But I do want a sane API
for Gecko talking to the bookmark and history impls. At the moment,
that API consists of:

nsICharsetResolver (on the bookmarks service)
nsIGlobalHistory (FROZEN; very basic)
nsIGlobalHistory2 (allows us to work with minor things like non-ASCII
URIs, notify history about redirects, handle page
titles, and store Gecko-specific per-URI flags).

The fact that this last is not frozen is highly unfortunate (see bug
234636). I'd almost rather we froze it and put new stuff in
nsIGlobalHistory3, but I'd need to look up the specific changes we're
making to say for sure.

-Boris


-Boris

Benjamin Smedberg

unread,
Jan 3, 2006, 8:49:19 PM1/3/06
to Boris Zbarsky
Boris Zbarsky wrote:
> bre...@gmail.com wrote:
>> Bookmark APIs will break
>
> Does that include the XPCOM apis that core calls (and embeddors
> implement)? If so, I'm not incredibly happy about breaking them (though
> see comments on 1.8.x vs 1.8.0.x in my previous post).

From my discussions with Brett, the places work will not alter
nsIGlobalHistory2 on the branch.

Gecko doesn't deal with bookmarks at all, so we're "safe" there.
(nsICharsetResolver is or could be unchanged, from what I can tell.) In
fact, I don't think that places uses "nsIBookmarksService" at all, so we can
safely claim that we're not changing that API, we're just stopping
implementing it.

> Frankly, I think that designing our core XPCOM apis (to be used by all
> bookmark and history implementations built on top of Gecko) around the

History and bookmarks are different in this case: history is called by gecko
and therefore requires intense cooperation between gecko and the embedder,
while bookmarks doesn't.

> nsIGlobalHistory2 (allows us to work with minor things like non-ASCII
> URIs, notify history about redirects, handle page
> titles, and store Gecko-specific per-URI flags).
>
> The fact that this last is not frozen is highly unfortunate (see bug
> 234636). I'd almost rather we froze it and put new stuff in
> nsIGlobalHistory3, but I'd need to look up the specific changes we're
> making to say for sure.

There have already been changes to nsIGlobalHistory2 on the trunk after 1.8
branched. I don't like it either, because I wanted to freeze it for 1.7, but
that ship has sailed.

--BDS

Boris Zbarsky

unread,
Jan 3, 2006, 9:10:07 PM1/3/06
to
Benjamin Smedberg wrote:
> History and bookmarks are different in this case: history is called by
> gecko and therefore requires intense cooperation between gecko and the
> embedder, while bookmarks doesn't.

Except that with Places bookmark UI design decisions are affecting the proposed
history APIs, as far as I can tell. So I stand by my point.

-Boris

Benjamin Smedberg

unread,
Jan 3, 2006, 9:31:54 PM1/3/06
to Boris Zbarsky

It is silly to expect that the UI design would not affect the APIs... what
exactly do you expect to be done differently? Trying to design "universal
APIs" to anticipate every future need does not seem reasonable or cost
effective.

--BDS

Boris Zbarsky

unread,
Jan 3, 2006, 9:38:28 PM1/3/06
to
Benjamin Smedberg wrote:
> Boris Zbarsky wrote:
>> Benjamin Smedberg wrote:
>> > History and bookmarks are different in this case: history is called by
>> > gecko and therefore requires intense cooperation between gecko and the
>> > embedder, while bookmarks doesn't.
>>
>> Except that with Places bookmark UI design decisions are affecting the
>> proposed history APIs, as far as I can tell. So I stand by my point.
>
> It is silly to expect that the UI design would not affect the APIs...

Again. _Bookmark_ UI design is affecting _history_ embedding APIs. At least
that's as I understand things at the moment; I'm still catching up on the Places
work plan and arch.

> what exactly do you expect to be done differently? Trying to design
> "universal APIs" to anticipate every future need does not seem
> reasonable or cost effective.

At the same time, designing the API strictly around the UI we want right this
minute seems narrow minded. I think it's worth investing a tiny bit of time now
to see whether the API needs anything else as long as we're changing or
enhancing it. I'm not saying it needs to be universal, and perhaps the things
being added for Places are all that seems obviously useful. I do think that
letting UI drive API design would work better if we had more input from
embeddors on what APIs they'd want -- that way we would end up with core APIs
designed around the Mozilla-browser-UI-of-the-day (which has a way of changing).

-Boris

Zbigniew Braniecki

unread,
Jan 4, 2006, 12:54:04 PM1/4/06
to
Benjamin Smedberg napisał(a):

> Axel Hecht wrote:
>
>> I'm still blurry about how to cope with the branches on the l10n side.
>> I'm tempted to drop the trunk alltogether for the time being. I'm not
>> sure when it should kick back in, though, probably before a fx3 alpha.
>> But that doesn't appear on the roadmap at all. I'm afraid I need way
>> more details for a reliable planning.
>
> Why would we drop the trunk l10n? The build machinery is already there,
> why not let localizers keep up to date if they wish? It would be nice
> for me as we work on xulrunner+firefox to keep l10n repackaging up to
> date rather than wait forever and discover problems at the last minute.


We were discussing this with Pike on Fx summit. I understand the reason
behind your worry, but think about localizers. Imho it's a huge waste of
resources to have them working on the trunk while it's in flames for
such a long time. Think about many people working to keep "the tree
green" while devs are messing without all xul/dtd files without a shame.

For a long time now, localizers are working on "tinderbox" routines, and
do everything possible to keep "the tree green". I find it very OK in
term of branch/pre release, but it's not OK if we're almost a year
before the release.
I'd prefer not to tempt them and at least take off trunk l10n
tinderboxes, and turn them on per request.

Greetings
Zbigniew Braniecki

Benjamin Smedberg

unread,
Jan 4, 2006, 1:11:46 PM1/4/06
to Zbigniew Braniecki
Zbigniew Braniecki wrote:

> We were discussing this with Pike on Fx summit. I understand the reason
> behind your worry, but think about localizers. Imho it's a huge waste of
> resources to have them working on the trunk while it's in flames for
> such a long time. Think about many people working to keep "the tree
> green" while devs are messing without all xul/dtd files without a shame.

There is a vast difference between "you don't have to update your trunk l10n
and keep your tbox green" and "the trunk is dead for l10n, don't checkin".
The latter option seems patently absurd to me. Leaving trunk l10n open is
extremely low-cost.

--BDS

Zbigniew Braniecki

unread,
Jan 4, 2006, 2:24:31 PM1/4/06
to
Benjamin Smedberg napisał(a):

> There is a vast difference between "you don't have to update your trunk
> l10n and keep your tbox green" and "the trunk is dead for l10n, don't
> checkin". The latter option seems patently absurd to me. Leaving trunk
> l10n open is extremely low-cost.

Yes, I'm talking about the former, but I'm lobbying to turn on l10n
trunk tinderboxes only per request.

Greetings
Zbigniew Braniecki

Pavel Franc

unread,
Jan 4, 2006, 2:45:45 PM1/4/06
to

I can second this opinion.

Pike/whoever should state clearly that it is not recommended to work on
the trunk due to frequent changes and that localizers don't have to be
synced with en-US. And IMHO after this statement majority of localizers
won't bother with the trunk anymore. There are 3-4 locales that are now
somehow synced with en-US, so let use them to track the l10n issues of
trunk and set the t-box for them per request.

More important question for localizers is what is the situation with
1.8.0/1.8 branches. As I know, some of them didn't start to work on
trunk but are eager to start work on FF 2.0 stuff - like places.

Pavel Franc

Axel Hecht

unread,
Jan 7, 2006, 10:39:41 AM1/7/06
to
I'm having another question on the l10n part of this, the wiki mentions

#ifdef MOZILLA_1_8_BRANCH

stuff, now, the l10n files aren't preprocessed (and there is somewhat of
a consensus that it'd be a bad idea if they were, as that may make
language packs depend on platform).

So, what does this mean for l10n-impacting divergence in UI?

We could ifdef in the xul and have something like foo.label.18 for the
branch or something, but that sounds sub-optimal.

Any better ideas?

Axel

PS: my current thinking is to try to use cross-commit, but as you see
above, I'm not sure if that will work.

Brendan Eich

unread,
Jan 8, 2006, 11:43:23 PM1/8/06
to Boris Zbarsky
Boris Zbarsky wrote:
> I'm not saying it needs to be
> universal,


Of course you aren't, because that would be utopian and therefore silly
or dangerous ;-).


> and perhaps the things being added for Places are all that
> seems obviously useful.


Better to look first before leaping?


> I do think that letting UI drive API design
> would work better if we had more input from embeddors on what APIs
> they'd want


Sorry, I don't believe in a committee approach to back end API design.
I'd rather see the dominant front end have its way with the back end,
and I'm being deliberately provocative here to make a point. Since
utopia is not an option, the best we can hope for is some foresight in
abstracting so that the back end does not dictate UI and interaction
design decisions.

AFAICT, the new APIs do not do that. Please point out any problems I'm
missing.


> -- that way we would end up with core APIs designed around
> the Mozilla-browser-UI-of-the-day (which has a way of changing).


But has the virtue of being what people actually use.

If in my provocatively-put worst case, we thrash the back end, but users
of Firefox (the by-far market share leading among embedders) are well
served in each release, then what exactly was done badly? The API churn
reflected not only front-end focus, but lack of compelling inputs in
other API directions.

It seems wrong to complain about missed future opportunities, at this
point. Bookmarks and history are a mess, not only in Firefox but in
most browsers.

/be

Brendan Eich

unread,
Jan 8, 2006, 11:46:48 PM1/8/06
to Boris Zbarsky, Darin Fisher, bre...@gmail.com
Boris Zbarsky wrote:
> Brendan Eich wrote:
>
>> Bookmarks and history non-frozen APIs are candidates for breakage,
>> given the wins of the Places work. The benefits outweigh the costs
>> and I think someone said some of the old APIs are too painful to
>> emulate on the new back end.
>
>
>
> Does "old APIs" here mean the frozen ones?


No.


> Because we MUST continue to
> support them. That's what it means for them to be frozen and all.


No need to remind me of that!


>> I'm not sure what interfaces will actually be broken, though.
>
>
> I've seen at least one patch floating around that changes the current
> global history API in an incompatible manner (changes signature of a
> method early in the vtable).


Do you mean nsIGlobalHistory2?


> Then again, this is primarily an issue for embeddors, and I guess our
> story for embeddors is to use the 1.8.0.x branch?


No, 1.8.1 should preserve frozen interface compatibility.

/be

Boris Zbarsky

unread,
Jan 9, 2006, 12:59:06 AM1/9/06
to
Brendan Eich wrote:
>> and perhaps the things being added for Places are all that seems
>> obviously useful.
>
> Better to look first before leaping?

Yes.

>> I do think that letting UI drive API design would work better if we
>> had more input from embeddors on what APIs they'd want
>
> Sorry, I don't believe in a committee approach to back end API design.

Did I suggest a committee? I said that the people or person doing the designing
should perhaps consider a wider range of use cases than we've historically
considered.

> I'd rather see the dominant front end have its way with the back end,

Then we easily end up in situations like nsWebBrowser -- forked APIs, forked
implementations, more code to maintain, and more effort all around to make all
the forks use the same code "eventually".

In my opinion, of course.

> Since utopia is not an option, the best we can hope for is some foresight in
> abstracting so that the back end does not dictate UI and interaction
> design decisions.

Yes, that's all I'm asking for. :)

> AFAICT, the new APIs do not do that. Please point out any problems I'm
> missing.

I'm still sorting through the new APIs. Will get back to you on this if I find
anything.

> But has the virtue of being what people actually use.

The cost being that in the worst case every time what people use changes we have
to do lots of changes under the hood (which people don't see, hence think we did
nothing) just to not backslide.

> If in my provocatively-put worst case, we thrash the back end, but users
> of Firefox (the by-far market share leading among embedders) are well
> served in each release

My point is that they would not be as well-served as the could be (because we'd
be wasting our time thrashing the back end instead of doing something productive).

> It seems wrong to complain about missed future opportunities, at this
> point.

I'm not complaining; just inquiring. ;)

> Bookmarks and history are a mess, not only in Firefox but in
> most browsers.

I don't see how that's relevant here.

-Boris

Boris Zbarsky

unread,
Jan 9, 2006, 1:01:43 AM1/9/06
to Brendan Eich, Darin Fisher, bre...@gmail.com
Brendan Eich wrote:
>> Does "old APIs" here mean the frozen ones?
>
> No.

OK, good. :)

>> I've seen at least one patch floating around that changes the current
>> global history API in an incompatible manner (changes signature of a
>> method early in the vtable).
>
> Do you mean nsIGlobalHistory2?

Yes.

>> Then again, this is primarily an issue for embeddors, and I guess our
>> story for embeddors is to use the 1.8.0.x branch?
>
> No, 1.8.1 should preserve frozen interface compatibility.

The frozen history interface is, frankly, useless as far as writing a real
history impl (one that sanely handles non-ASCII URIs, say) goes. We really
should have frozen nsIGlobalHistory2 for 1.7 or 1.8, but people had too much
stuff on their plates, as usually happens. :(

I believe there was some consensus in the bug where this patch was that we
should try to put the new stuff on a new interface, for what it's worth.

-Boris

Brendan Eich

unread,
Jan 9, 2006, 1:11:13 AM1/9/06
to Boris Zbarsky, Darin Fisher, bre...@gmail.com
Boris Zbarsky wrote:

> I believe there was some consensus in the bug where this patch was that
> we should try to put the new stuff on a new interface, for what it's worth.

Yeah, I heard that nsIGlobalHistory3 is the new thing.

I fussed about the name, but it's actually predictable and automatic.
Why shouldn't we follow the logic of [XP]COM? We may end up with lots
of interfaces, but if we inherit to extend, the incremental cost in vptr
space is zero, and the QIs shouldn't be above noise, or something
shouldn't be using XPCOM in the first place.

/be

Brendan Eich

unread,
Jan 9, 2006, 1:07:48 AM1/9/06
to Boris Zbarsky
Boris Zbarsky wrote:

>> Sorry, I don't believe in a committee approach to back end API design.
>
>
> Did I suggest a committee? I said that the people or person doing the
> designing should perhaps consider a wider range of use cases than we've
> historically considered.


In my experience, the only way to get consideration that matters (that
actually works for cases other than the ones being used and tested hard)
is a committee, or iteration among a group of implementors (which is a
kind of committee).


>> If in my provocatively-put worst case, we thrash the back end, but
>> users of Firefox (the by-far market share leading among embedders) are
>> well served in each release
>
>
> My point is that they would not be as well-served as the could be
> (because we'd be wasting our time thrashing the back end instead of
> doing something productive).


But this assumes the proposition that I question: that anyone can
generalize an API much beyond its actually-implemented, used and tested
use-cases. I'm an old hacker, with profound skepticism about claims of
API generality.


>> Bookmarks and history are a mess, not only in Firefox but in most
>> browsers.
>
>
> I don't see how that's relevant here.


What happened last time is usually relevant. Next time will differ how,
and why?

Last time, we had concreteness that bound us in certain ways, plus the
cost and generality (false, for the most part) of RDF, which didn't help
at all in switching to a tagging approach.

Better luck this time!

/be

Reply all
Reply to author
Forward
0 new messages