Proposed Changes to Toolkit ownership structure and reviews

classic Classic list List threaded Threaded
25 messages Options
12
Reply | Threaded
Open this post in threaded view
|

Proposed Changes to Toolkit ownership structure and reviews

Mike Connor-4
As a little background, there's been some private discussion about rejigging the way we break down ownership of the various parts of toolkit.  Ben asked me to take the detailed proposal public, so here goes:

Reviews getting to the right place often happens only because people are told who to ask by active community members.  There is no obvious way to find out by yourself who is the best person to ask for review, or who to ask for help in figuring out where to fix a bug, etc.  I believe in the principle of strong ownership, and with the size and breadth of toolkit its hard for any one person to be that owner.  Breaking things up into sub-modules should mean that there's a clear advocate and strong hacker acting as a strong owner for all of the code we're relying on.  The change in how we're defining members and how they gain responsibilities should help more people get involved and feel like they're being recognized, since its easier to establish a good track record with a smaller group before branching out.

This isn't absolutely necessary yet, with the current group of hackers, but I believe that adding the structure now will provide a better framework for adding new people to the group going forward.  I want to create a clearer progression for new people getting involved in FE hacking (get involved, get responsibility for a small area and start helping with reviews, branch out into wider areas and eventually become a peer for the whole toolkit) which reflects the module peer->owner->superreviewer progression that seems to have worked for Gecko in many cases.  It also allows people to not branch out, and just focus on the areas they're interested in working on, and still be given appropriate responsibility.  Its a bit more of a benevolent feudal system than our traditional benevolent dictatorship, but I think its time to start building a larger hierarchy of people so there's more perceived room to fit in.

The more I look at how things are being done, and who is taking the leadership roles, I'd like to propose Benjamin Smedberg as the overall toolkit owner.  Both on a technical level and with his focus on Mozilla-as-platform, he's obviously well-qualified, and he is doing the most to ensure that the toolkit is a strong platform.  This also means that there's a check and balance between the needs of the apps, and the needs of other apps not reflected in the current structure (Songbird, Nvu, Sunbird, etc).

I also propose that Rob Strong should be elevated from member to peer, and Neil Deakin should be added as a peer.

Proposed Toolkit ownership structure (bold means changes in despot)


Toolkit Technical Lead: Benjamin Smedberg (listed as owner in despot)
UI Group: Ben Goodger, Mike Beltzner, Mike Connor
Peers (shown in despot): Vladimir Vukicevic, Scott MacGregor, Neil Rashbrook, Michael Connor, Brian Ryner, Darin Fisher, Ben Goodger, Robert Strong, Neil Deakin
Members: Asaf Romano, Masayuki Nagano, Brett Wilson

Toolkit Sub-Modules

Sub-Module
Code covered
Owner
Other Reviewers
Toolkit bootstrapping and startup toolkit/xre, toolkit/library, toolkit/profile, toolkit/components/startup, toolkit/components/commandlines, toolkit/components/remote, toolkit/components/build
Benjamin Smedberg Darin Fisher
Toolkit general UI bits
toolkit/content, toolkit/components (for those not covered elsewhere)
Mike Connor
Neil Deakin, Neil Rashbrook, Asaf Romano
Extension Manager
toolkit/mozapps/extensions
Rob Strong
Benjamin Smedberg, Mike Connor, Ben Goodger
Installer
toolkit/mozapps/installer (and later, wherever NSIS lives)
Rob Strong
Benjamin Smedberg
Find Toolbar
toolkit/components/typeaheadfind
Mike Connor
Masayuki Nagano
Locales
toolkit/locales (build/packaging/policy stuff, string approvals are ui-review fodder)
Benjamin Smedberg
Axel Hecht
Prefwindow
toolkit/content/widgets/preferences.xml, toolkit/mozapps/preferences
Mike Connor
Ben Goodger, Asaf Romano
Download Manager
toolkit/components/downloads, toolkit/mozapps/downloads
Ben Goodger
Mike Connor, Neil Deakin
Password Manager/Satchel
toolkit/components/passwordmgr, toolkit/components/satchel,
Brian Ryner

Software Update
toolkit/mozapps/update
Darin Fisher
Ben Goodger, Benjamin Smedberg, Rob Strong
GNOME Integration bits
toolkit/components/gnome
Brian Ryner
Darin Fisher
Chrome Registry
chrome
Benjamin Smedberg
Darin Fisher, Neil Rashbrook
Storage
storage
Vladimir Vukicevic Darin Fisher, Brett Wilson, Brian Ryner
XULRunner
xulrunner
Benjamin Smedberg
Rob Strong, Darin Fisher

Review Rules:

Wherever possible, significant patches in a certain area should be reviewed by one of the listed sub-module owner/reviewers.
Peers may grant review in any area covered by toolkit, provided they feel confident in their knowledge of the code being changed.
One review is sufficient in most cases.  If the first reviewer feels that the patch would benefit from additional reviews, they should request a second review from an appropriate person.
Members may only grant review in areas they are listed as reviewers  (Author's note: this is to allow us to bring new people into certain areas without immediately giving them wide-ranging responsibility)
Significant UI changes should get UI review from someone in the UI group, along with code review.

Thoughts and feedback appreciated!

-- Mike

_______________________________________________
dev-planning mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-planning
Reply | Threaded
Open this post in threaded view
|

Re: Proposed Changes to Toolkit ownership structure and reviews

Andrew Schultz-2
Mike Connor wrote:
> GNOME Integration bits
> toolkit/components/gnome
> Brian Ryner
> Darin Fisher

Gnome is apparently moving.  See
https://bugzilla.mozilla.org/show_bug.cgi?id=331416

I didn't see autocomplete anywhere... It doesn't seem like a "Toolkit
general UI bit".  Could it be lumped in with Satchel?

--
Andrew Schultz
[hidden email]
http://www.sens.buffalo.edu/~ajs42/
_______________________________________________
dev-planning mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-planning
Reply | Threaded
Open this post in threaded view
|

Re: Proposed Changes to Toolkit ownership structure and reviews

Mike Connor-3
Andrew Schultz wrote:
> Mike Connor wrote:
>> GNOME Integration bits
>>     toolkit/components/gnome
>>     Brian Ryner
>>     Darin Fisher
>
> Gnome is apparently moving.  See
> https://bugzilla.mozilla.org/show_bug.cgi?id=331416

Man, you blink for a minute...

> I didn't see autocomplete anywhere... It doesn't seem like a "Toolkit
> general UI bit".  Could it be lumped in with Satchel?

Hmm, perhaps, there's a lot of overlap between the two.

Either way is ok, as long as there's consistency

-- Mike
_______________________________________________
dev-planning mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-planning
Reply | Threaded
Open this post in threaded view
|

Re: Proposed Changes to Toolkit ownership structure and reviews

Axel Hecht
In reply to this post by Mike Connor-4
Mike Connor wrote:

> As a little background, there's been some private discussion about
> rejigging the way we break down ownership of the various parts of
> toolkit.  Ben asked me to take the detailed proposal public, so here goes:
>
> Reviews getting to the right place often happens only because people are
> told who to ask by active community members.  There is no obvious way to
> find out by yourself who is the best person to ask for review, or who to
> ask for help in figuring out where to fix a bug, etc.  I believe in the
> principle of strong ownership, and with the size and breadth of toolkit
> its hard for any one person to be that owner.  Breaking things up into
> sub-modules should mean that there's a clear advocate and strong hacker
> acting as a strong owner for all of the code we're relying on.  The
> change in how we're defining members and how they gain responsibilities
> should help more people get involved and feel like they're being
> recognized, since its easier to establish a good track record with a
> smaller group before branching out.
>
> This isn't absolutely necessary yet, with the current group of hackers,
> but I believe that adding the structure now will provide a better
> framework for adding new people to the group going forward.  I want to
> create a clearer progression for new people getting involved in FE
> hacking (get involved, get responsibility for a small area and start
> helping with reviews, branch out into wider areas and eventually become
> a peer for the whole toolkit) which reflects the module
> peer->owner->superreviewer progression that seems to have worked for
> Gecko in many cases.  It also allows people to not branch out, and just
> focus on the areas they're interested in working on, and still be given
> appropriate responsibility.  Its a bit more of a benevolent feudal
> system than our traditional benevolent dictatorship, but I think its
> time to start building a larger hierarchy of people so there's more
> perceived room to fit in.
> _
> _The more I look at how things are being done, and who is taking the
> leadership roles, I'd like to propose Benjamin Smedberg as the overall
> toolkit owner.  Both on a technical level and with his focus on
> Mozilla-as-platform, he's obviously well-qualified, and he is doing the
> most to ensure that the toolkit is a strong platform.  This also means
> that there's a check and balance between the needs of the apps, and the
> needs of other apps not reflected in the current structure (Songbird,
> Nvu, Sunbird, etc).
>
> I also propose that Rob Strong should be elevated from member to peer,
> and Neil Deakin should be added as a peer.
> _
> Proposed Toolkit ownership structure (bold means changes in despot)_
>
> Toolkit Technical Lead: *Benjamin Smedberg* (listed as owner in despot)
> UI Group: Ben Goodger, Mike Beltzner, Mike Connor
> Peers (shown in despot): Vladimir Vukicevic, Scott MacGregor, Neil
> Rashbrook, Michael Connor, *Brian Ryner*, Darin Fisher, Ben Goodger,
> *Robert Strong, Neil Deakin*
> Members: Asaf Romano, *Masayuki Nagano, Brett Wilson*
>
> Toolkit Sub-Modules
>
> Sub-Module
> Code covered
> Owner
> Other Reviewers

<..>

> Locales
> toolkit/locales (build/packaging/policy stuff, string approvals are
> ui-review fodder)
> Benjamin Smedberg
> Axel Hecht

I'd rather have that the other way around, and I'm not sure what you
think is "ui-review fodder".

Axel
_______________________________________________
dev-planning mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-planning
Reply | Threaded
Open this post in threaded view
|

Re: Proposed Changes to Toolkit ownership structure and reviews

Ben Goodger
In reply to this post by Mike Connor-4
Thanks for taking the initiative on this, Mike. It is an excellent idea
to get clarity on the best people to review code. I think it will help
contributors a lot.

A note on the UI/app-specific pieces after some reflection:

I think "owner" is may not the best word for some pieces, specifically
the UI and stuff that's not designed to be part of the XRE. These pieces
were separated out of browser/ and mail/ and placed in toolkit/ for the
purpose of shared utility, and it was never Scott or my intent (I don't
believe, Scott can correct me if I'm wrong) that these pieces should be
"separate" modules.

For these pieces, I think a better word for those sections is
"reviewers" - especially since that meets the needs of the target
audience for these changes.

What do you think?

-Ben


_______________________________________________
dev-planning mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-planning
Reply | Threaded
Open this post in threaded view
|

Re: Proposed Changes to Toolkit ownership structure and reviews

Benjamin Smedberg
Ben Goodger wrote:

> Thanks for taking the initiative on this, Mike. It is an excellent idea
> to get clarity on the best people to review code. I think it will help
> contributors a lot.
>
> A note on the UI/app-specific pieces after some reflection:
>
> I think "owner" is may not the best word for some pieces, specifically
> the UI and stuff that's not designed to be part of the XRE. These pieces
> were separated out of browser/ and mail/ and placed in toolkit/ for the
> purpose of shared utility, and it was never Scott or my intent (I don't
> believe, Scott can correct me if I'm wrong) that these pieces should be
> "separate" modules.
>
> For these pieces, I think a better word for those sections is
> "reviewers" - especially since that meets the needs of the target
> audience for these changes.

What pieces are you talking about in particular? We ship basically all of
toolkit/ as part of the XRE, except for the code in
toolkit/mozapps/installer.  I don't unerstand the distinction being made.

--BDS
_______________________________________________
dev-planning mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-planning
Reply | Threaded
Open this post in threaded view
|

Re: Proposed Changes to Toolkit ownership structure and reviews

Ben Goodger
Benjamin Smedberg wrote:
> What pieces are you talking about in particular? We ship basically all
> of toolkit/ as part of the XRE, except for the code in
> toolkit/mozapps/installer.  I don't unerstand the distinction being made.

 From a pure architecture/hygiene point of view that doesn't seem like
the best idea.

IMO, inside toolkit/ XRE = application bootstrapping, XUL toolkit, core
services.

There is other stuff in there like some of the stuff in mozapps/ -
shared pref panels, etc. Those shouldn't be part of XRE. That was my
argument for having mozapps be a toplevel dir back when it was created,
or at least cls' proposed:

mozilla/apps/shared <-- toolkit/mozapps
mozilla/apps/browser
mozilla/apps/mail
...

... plus some additional UI stuff in toolkit/content, like the customize
toolbars dialog.

-Ben
_______________________________________________
dev-planning mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-planning
Reply | Threaded
Open this post in threaded view
|

Re: Proposed Changes to Toolkit ownership structure and reviews

Benjamin Smedberg
Ben Goodger wrote:
> Benjamin Smedberg wrote:
>> What pieces are you talking about in particular? We ship basically all
>> of toolkit/ as part of the XRE, except for the code in
>> toolkit/mozapps/installer.  I don't unerstand the distinction being made.
>
>  From a pure architecture/hygiene point of view that doesn't seem like
> the best idea.

What isn't?

> IMO, inside toolkit/ XRE = application bootstrapping, XUL toolkit, core
> services.
>
> There is other stuff in there like some of the stuff in mozapps/ -
> shared pref panels, etc. Those shouldn't be part of XRE. That was my
> argument for having mozapps be a toplevel dir back when it was created,
> or at least cls' proposed:

I'm not sure about the shared pref panels: what are they and why aren't they
useful or potentially useful for non-mozilla apps? When making decisions
about whether code ought to be shipped in Firefox or XULRunner (code which
is going to be shipped in Firefox anyway, so it's a zero-sum game), my
strong preference is to err on the side of XULRunner.

> ... plus some additional UI stuff in toolkit/content, like the customize
> toolbars dialog.

This should absolutely be included in xulrunner: the functionality of
automatically-provided customizable toolbars is a major selling point of the
platform.

--BDS
_______________________________________________
dev-planning mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-planning
Reply | Threaded
Open this post in threaded view
|

Re: Proposed Changes to Toolkit ownership structure and reviews

Ben Goodger
Benjamin Smedberg wrote:
> I'm not sure about the shared pref panels: what are they and why aren't
> they useful or potentially useful for non-mozilla apps? When making
> decisions about whether code ought to be shipped in Firefox or XULRunner
> (code which is going to be shipped in Firefox anyway, so it's a zero-sum
> game), my strong preference is to err on the side of XULRunner.

They're things like the downloads pref panel for Firefox/Thunderbird.

>> ... plus some additional UI stuff in toolkit/content, like the
>> customize toolbars dialog.
>
> This should absolutely be included in xulrunner: the functionality of
> automatically-provided customizable toolbars is a major selling point of
> the platform.

OK, but should the UI (which ships with Firefox and Thunderbird) be a
separate module developed independently of the other two? I don't think so.

-Ben
_______________________________________________
dev-planning mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-planning
Reply | Threaded
Open this post in threaded view
|

Re: Proposed Changes to Toolkit ownership structure and reviews

Darin Fisher-2
In reply to this post by Benjamin Smedberg
On 3/30/06, Benjamin Smedberg <[hidden email]> wrote:

> Ben Goodger wrote:
> > Benjamin Smedberg wrote:
> >> What pieces are you talking about in particular? We ship basically all
> >> of toolkit/ as part of the XRE, except for the code in
> >> toolkit/mozapps/installer.  I don't unerstand the distinction being made.
> >
> >  From a pure architecture/hygiene point of view that doesn't seem like
> > the best idea.
>
> What isn't?
>
> > IMO, inside toolkit/ XRE = application bootstrapping, XUL toolkit, core
> > services.
> >
> > There is other stuff in there like some of the stuff in mozapps/ -
> > shared pref panels, etc. Those shouldn't be part of XRE. That was my
> > argument for having mozapps be a toplevel dir back when it was created,
> > or at least cls' proposed:
>
> I'm not sure about the shared pref panels: what are they and why aren't they
> useful or potentially useful for non-mozilla apps? When making decisions
> about whether code ought to be shipped in Firefox or XULRunner (code which
> is going to be shipped in Firefox anyway, so it's a zero-sum game), my
> strong preference is to err on the side of XULRunner.
>
> > ... plus some additional UI stuff in toolkit/content, like the customize
> > toolbars dialog.
>
> This should absolutely be included in xulrunner: the functionality of
> automatically-provided customizable toolbars is a major selling point of the
> platform.
>
> --BDS


Bsmedberg,

What happens when FF/TB wishes to rework these shared UI elements in a
manner that breaks other XRE-consumers?  I think our toolkit-derived
apps need a place to stick shared code that can be rapidly evolved w/o
concern for API stability.  At the same time, API stability is a very
important goal of the XRE (or at least it should be), so we have a bit
of a conflict there.

-Darin
_______________________________________________
dev-planning mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-planning
Reply | Threaded
Open this post in threaded view
|

Re: Proposed Changes to Toolkit ownership structure and reviews

Benjamin Smedberg
In reply to this post by Benjamin Smedberg
Darin Fisher wrote:

> Bsmedberg,
>
> What happens when FF/TB wishes to rework these shared UI elements in a
> manner that breaks other XRE-consumers?  I think our toolkit-derived
> apps need a place to stick shared code that can be rapidly evolved w/o
> concern for API stability.  At the same time, API stability is a very
> important goal of the XRE (or at least it should be), so we have a bit
> of a conflict there.

How is reworking this UI different from other changes or non-UI changes?
Obviously we haven't frozen any system to launch the toolbar customization
dialog, because:

1) we haven't defined an API for this at all! people include the JS file
and/or open the customizeToolbar dialog directly.
2) XUL itself isn't frozen

At some point we're going to want to define an API for launching the toolbar
customization code, but that doesn't mean we need to freeze the actual look
or behavior of the dialog.

The same rules apply for displaying the extension manager, the help viewer,
and whatnot.

I think that we should treat this code the same way we treat
rapidly-evolving non-UI code: it's not frozen, we'll define and freeze APIs
for this when it stabilizes; in the meantime, use at your own risk.

--BDS
_______________________________________________
dev-planning mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-planning
Reply | Threaded
Open this post in threaded view
|

Re: Proposed Changes to Toolkit ownership structure and reviews

Robert Kaiser
In reply to this post by Ben Goodger
Ben Goodger schrieb:
> There is other stuff in there like some of the stuff in mozapps/ -
> shared pref panels, etc. Those shouldn't be part of XRE. That was my
> argument for having mozapps be a toplevel dir back when it was created,

Yes, mozapps to a big part sounds to me like something one should be
able to at least opt-out, better even only have in an opt-in model in a
XULRunner app.

Now that we are trying to get SeaMonkey working with toolkit, we saw for
example that some components are installed that other XULRunner apps
might not want - they might even want to not have EM turned on in their
app, same with the update service, the plugins stuff or helperAppDlg.
Or they may want to ship their own, different implementations of those,
and the mozapps components might clash with theirs.

We might want all or most of those in SeaMonkey (though we might want to
use different download manager chrome, for example) - for other,
non-Mozilla apps that might be different though.

Robert Kaiser
_______________________________________________
dev-planning mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-planning
Reply | Threaded
Open this post in threaded view
|

Re: Proposed Changes to Toolkit ownership structure and reviews

Darin Fisher-2
XULRunner allows apps to enable/disable EM and Profile Migrator from
application.ini.

-Darin



On 3/30/06, Robert Kaiser <[hidden email]> wrote:

> Ben Goodger schrieb:
> > There is other stuff in there like some of the stuff in mozapps/ -
> > shared pref panels, etc. Those shouldn't be part of XRE. That was my
> > argument for having mozapps be a toplevel dir back when it was created,
>
> Yes, mozapps to a big part sounds to me like something one should be
> able to at least opt-out, better even only have in an opt-in model in a
> XULRunner app.
>
> Now that we are trying to get SeaMonkey working with toolkit, we saw for
> example that some components are installed that other XULRunner apps
> might not want - they might even want to not have EM turned on in their
> app, same with the update service, the plugins stuff or helperAppDlg.
> Or they may want to ship their own, different implementations of those,
> and the mozapps components might clash with theirs.
>
> We might want all or most of those in SeaMonkey (though we might want to
> use different download manager chrome, for example) - for other,
> non-Mozilla apps that might be different though.
>
> Robert Kaiser
> _______________________________________________
> dev-planning mailing list
> [hidden email]
> https://lists.mozilla.org/listinfo/dev-planning
>
_______________________________________________
dev-planning mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-planning
Reply | Threaded
Open this post in threaded view
|

Re: Proposed Changes to Toolkit ownership structure and reviews

Robert Kaiser
In reply to this post by Robert Kaiser
Darin Fisher schrieb:
> XULRunner allows apps to enable/disable EM and Profile Migrator from
> application.ini.

Hmm, what about apps that are building with toolkit (MOZ_XUL_APP=1) but
aren't yet runninf fully on top of XULRunner (like SeaMonkey in the
transition phase)?
What about other mozapps components than those two (in our case, EM is a
non-issue, should be enabled from the beginning and we also need some
profile migrator soon, either that one r something similar)?

Robert Kaiser
_______________________________________________
dev-planning mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-planning
Reply | Threaded
Open this post in threaded view
|

Re: Proposed Changes to Toolkit ownership structure and reviews

Darin Fisher-2
On 3/31/06, Robert Kaiser <[hidden email]> wrote:

> Darin Fisher schrieb:
> > XULRunner allows apps to enable/disable EM and Profile Migrator from
> > application.ini.
>
> Hmm, what about apps that are building with toolkit (MOZ_XUL_APP=1) but
> aren't yet runninf fully on top of XULRunner (like SeaMonkey in the
> transition phase)?
> What about other mozapps components than those two (in our case, EM is a
> non-issue, should be enabled from the beginning and we also need some
> profile migrator soon, either that one r something similar)?

Well, XULRunner just calls XRE_Main with configuration parameters
extracted from application.ini.  So, you should be able to skip the
application.ini step, and just call XRE_Main with the configuration
parameters of your choosing.

-Darin
_______________________________________________
dev-planning mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-planning
Reply | Threaded
Open this post in threaded view
|

Re: Proposed Changes to Toolkit ownership structure and reviews

Mark Banner
In reply to this post by Robert Kaiser
Darin Fisher wrote:
> XULRunner allows apps to enable/disable EM and Profile Migrator from
> application.ini.
>
> -Darin

Yes, but what about the other mozapps components - in either the
XULRunner or toolkit/XRE case there is no option (as I read
nsXULAppAPI.h) to disable Download Manager, which SeaMonkey currently
wants to do.

Standard8
_______________________________________________
dev-planning mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-planning
Reply | Threaded
Open this post in threaded view
|

Re: Proposed Changes to Toolkit ownership structure and reviews

Darin Fisher-2
Download Manager is not something that is invoked during XRE startup.
The configuration flags passed to XRE_Main are meant to affect the XRE
startup phase.  For example, EM may require the application to restart
during XRE startup.  Profile Migrator may be launched by XRE startup
when there is no pre-existing profile.  Download Manager on the other
hand is something that your application code invokes, so you can
control from your application code whether or not to use the Toolkit
supplied Download Manager.

-Darin



On 4/2/06, Standard8 <[hidden email]> wrote:

> Darin Fisher wrote:
> > XULRunner allows apps to enable/disable EM and Profile Migrator from
> > application.ini.
> >
> > -Darin
>
> Yes, but what about the other mozapps components - in either the
> XULRunner or toolkit/XRE case there is no option (as I read
> nsXULAppAPI.h) to disable Download Manager, which SeaMonkey currently
> wants to do.
>
> Standard8
> _______________________________________________
> dev-planning mailing list
> [hidden email]
> https://lists.mozilla.org/listinfo/dev-planning
>
_______________________________________________
dev-planning mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-planning
Reply | Threaded
Open this post in threaded view
|

Re: Proposed Changes to Toolkit ownership structure and reviews

Christian Biesinger
Darin Fisher wrote:
> Download Manager on the other
> hand is something that your application code invokes, so you can
> control from your application code whether or not to use the Toolkit
> supplied Download Manager.

Are components in the application's directory guaranteed to override
XULRunner components?
_______________________________________________
dev-planning mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-planning
Reply | Threaded
Open this post in threaded view
|

Re: Proposed Changes to Toolkit ownership structure and reviews

Darin Fisher-2
Probably.  It should happen that the application's chrome.manifest is
parsed after the toolkit's.  If that is true, then yes :-)

-Darin


On 4/3/06, Christian Biesinger <[hidden email]> wrote:

> Darin Fisher wrote:
> > Download Manager on the other
> > hand is something that your application code invokes, so you can
> > control from your application code whether or not to use the Toolkit
> > supplied Download Manager.
>
> Are components in the application's directory guaranteed to override
> XULRunner components?
> _______________________________________________
> dev-planning mailing list
> [hidden email]
> https://lists.mozilla.org/listinfo/dev-planning
>
_______________________________________________
dev-planning mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-planning
Reply | Threaded
Open this post in threaded view
|

Re: Proposed Changes to Toolkit ownership structure and reviews

Benjamin Smedberg
In reply to this post by Darin Fisher-2
Christian Biesinger wrote:
> Darin Fisher wrote:
>> Download Manager on the other
>> hand is something that your application code invokes, so you can
>> control from your application code whether or not to use the Toolkit
>> supplied Download Manager.
>
> Are components in the application's directory guaranteed to override
> XULRunner components?

I believe that on trunk this is true, making the assumption that nobody is
calling nsIComponentRegistrar.autoRegister manually (allowing the default
toolkit and xpcom autoregistration code follow its natural codepath).

This should also be true for chrome registration manifests. Both sets of
registrations should happen in the following order:

1. xulrunner (==GRE)
2. app
3. extensions (internal ordering of extension registration is unspecified)
4. other directories specified by custom directoryserviceproviders

--BDS
_______________________________________________
dev-planning mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-planning
12