Consolidation of Core components
Benjamin Smedberg
filers to know which one to choose, and having so many does not help
searching. I am proposing the following consolidations based on the
following criterion: the important thing in categories is that knowledgable
hackers see incoming bugs (through watcher emails or saved queries) without
being inundated with too many bugs. Therefore I have grouped the products by
"the hackers who work on them":
DOM:
from the current components
DOM
DOM to Text Conversion
DOM: Abstract Schemas
DOM: Core
DOM: Events
DOM: HTML
DOM: Level 0
DOM: Load and Save
DOM: Mozilla Extensions
DOM: Traversal-Range"
DOM: Validation
DOM: Views and Formatting
Rename "DOM: CSSOM" to "DOM CSS Object Model"
Embedding:
from the current components
Embedding: ActiveX Wrapper
Embedding: APIs
Embedding: GRE Core
Embedding: GTK Widget
Embedding: Mac
Embedding: MFC Embed
Embedding: Packaging
Installer: GRE
Installer: MFCEmbed
I tend to think all of GFX should be lumped together but I'm less certain
about that, so I'd ask roc to chime in about that.
Document Navigation (docshell):
from the current components
Embedding: Docshell
History: Session
Layout: Positioning
from the current components
Layout
Layout: Block and Inline
Layout: Floats
Layout: HTML Frames
Layout: Misc Code
Layout: R & A Pos
Layout: Text
from the current components
Layout: BiDi Hebrew & Arabic
Layout: CTL
Layout: Fonts and Text
Layout: Graphics
from the current components
Layout: Images
Layout: Canvas
Layout: View Rendering
Networking
from the current components
Networking
Networking: Cache
Networking: Cookies
Networking: File
Networking: FTP
Networking: HTTP
Networking: JAR
I think this has already been discussed to some extent, but:
XUL language:
from the current components
XP Toolkit/Widgets
XP Toolkit/Widgets: Menus
XP Toolkit/Widgets: Trees
XP Toolkit/Widgets: XUL
and also from Toolkit: XUL Widgets
XPCOM:
from the current components
XPCOM
XPCOM registry
xpidl
--BDS
L. David Baron
> DOM:
> from the current components
> DOM
> DOM to Text Conversion
> DOM: Abstract Schemas
> DOM: Core
> DOM: Events
> DOM: HTML
> DOM: Level 0
> DOM: Load and Save
> DOM: Mozilla Extensions
> DOM: Traversal-Range"
> DOM: Validation
> DOM: Views and Formatting
>
> Rename "DOM: CSSOM" to "DOM CSS Object Model"
I suspect many of these distintions are useful, although I'm not
sure. I'd also note that "DOM to Text Conversion" has little to do
with DOM.
> Layout: Positioning
> from the current components
> Layout
> Layout: Block and Inline
> Layout: Floats
> Layout: HTML Frames
> Layout: Misc Code
> Layout: R & A Pos
I'm against this. I think we could get rid of "HTML Frames", but I
think the rest of these distinctions are useful. And I'm strongly
against the name "Layout: Positioning", since it implies a
connection to the 'position' property.
> Layout: Text
> from the current components
> Layout: BiDi Hebrew & Arabic
> Layout: CTL
> Layout: Fonts and Text
This seems reasonable to me, although the "BiDi Hebrew & Arabic"
bugs would really need to be triaged into various components, and
many of the CTL bugs are probably now invalid/worksforme.
> Layout: Graphics
> from the current components
> Layout: Images
> Layout: Canvas
> Layout: View Rendering
I like having a component for painting bugs, and I think this
component name relies on using Graphics to mean two very different
things (graphical issues with everything; layout issues related to
graphical objects). It might be reasonable to combine Canvas and
Images, although the bigger issue with the images components is the
distinction between ImageLib, Image: GFX, and Layout: Images. I'd
suggest keeping the distinction between the components (since pretty
different people work on them) but using the Image: prefix for all
three (something like Image: Decoding, Image: Painting, Image:
Layout).
> I think this has already been discussed to some extent, but:
> XUL language:
> from the current components
> XP Toolkit/Widgets
> XP Toolkit/Widgets: Menus
> XP Toolkit/Widgets: Trees
> XP Toolkit/Widgets: XUL
> and also from Toolkit: XUL Widgets
So bugs against the layout algorithms in nsSprocketLayout and the
XBL code in toolkit/content/widgets/ go in the same component? That
seems pretty broad.
-David
--
L. David Baron <URL: http://dbaron.org/ >
Technical Lead, Layout & CSS, Mozilla Corporation
Boris Zbarsky
> DOM:
...
> DOM to Text Conversion
This has nothing to do with "DOM", per se. This is basically serializers and
encoders... Used for DOMSerializer, form controls, editor, etc. Maybe this
should just be renamed to make that clearer?
> DOM: Events
The code corresponding to this is pretty distinct from a lot of the DOM. More
importantly, the set of people working on it is not the same as, say, for DOM Core.
One question I have is what the goal here is. Is it to make filers' life
easier? Or developers'? Or both? I can see a developer watching the DOM:
Events component to keep track of new bugs in his area of expertise. I don't
see a developer watching all the DOM components we have now just so he can fix
event bugs...
What would make a lot of sense to me is consolidating little-used DOM stuff
(Abstract Schemas, Validation, Views and Formatting, Load & Save, and maybe
Traversal/Range) into "DOM: Other". Possibly also DOM: Mozilla extensions.
Also consolidating DOM, DOM: Core, and DOM: Level 0, and maybe DOM: HTML into a
single "DOM" or "DOM: Core" product.
> Embedding:
For what it's worth, I currently watch apis, docshell, and gre@embedding. I'm
not sure I'd be so interested in a lot of this other stuff, but maybe it's
low-traffic enough that I could continue to watch the "Embedding" component...
> Document Navigation (docshell):
> from the current components
> Embedding: Docshell
> History: Session
Hmm... Yeah, I guess we could make that work...
> Layout: Positioning
> from the current components
> Layout
> Layout: Block and Inline
> Layout: Floats
> Layout: HTML Frames
> Layout: Misc Code
> Layout: R & A Pos
This has problems similar to DOM. For example, I've watched "R&A Pos" in the
past when I was well on top of how it worked, but I wouldn't want to watch the
entirety of the components listed here.
These components really do correspond to the way the code breaks down
functionally, which brings us back to the question of whose benefit the changes
are mainly for.
> Networking
Not quite sure about this one. Ideally, we'd have enough people working on
networking that multiple watchable bits would make sense (e.g. have a cache
specialist who could watch all the cache stuff), but we just don't. Do we want
to assume that we never will again?
Similar for cookies; in the past we've had people who actively focused on it,
and finding cookie bugs in general Networking woudl be tough.
We also used to have a semi-dedicated FTP owner...
dbaron covered what I think about the image/view/etc stuff.
-Boris
timeless
> > Networking
>
> Not quite sure about this one. Ideally, we'd have enough people working on
> networking that multiple watchable bits would make sense (e.g. have a cache
> specialist who could watch all the cache stuff), but we just don't. Do we want
> to assume that we never will again?
we occasionally have a cache person, and i suspect we'll have one when
it gets rewritten again.
please don't merge them.
Akkana Peck
> Benjamin Smedberg wrote:
> > DOM to Text Conversion
>
> This has nothing to do with "DOM", per se. This is basically serializers and
> encoders... Used for DOMSerializer, form controls, editor, etc. Maybe this
> should just be renamed to make that clearer?
How about "Serializers" or "Serializers/Encoders"? Newbies won't
know what that means, but folks doing bug triage probably should,
and the current name is misleading and awkward (and no clearer
to newbies).
The current name was chosen back when the serializers were new and
nobody much used that term. The name they had before was much more
misleading (it was something like "Text/HTML Output" and people kept
filing printing bugs against it).
...Akkana
Gervase Markham
> One question I have is what the goal here is. Is it to make filers'
> life easier? Or developers'? Or both?
Both, tradeoff, yada yada. But probably prioritising developers over
filers; developers use Bugzilla more, and we can add guides and help
text to bug entry for filters.
I'd err on the site of not amalgamating unless people currently working
in that area want it, or the code is so intertwined that it's hard for a
knowledgeable person to correctly classify the bug.
Gerv
Gervase Markham
* "DOM to Text Conversion" -> Serializers
* "DOM" from
DOM
DOM: Core
DOM: Level 0
DOM: HTML
* DOM: Events remains as-is.
* dbaron wants to keep the distinctions between the below; bz wants to
combine them into DOM: Other:
DOM: Load and Save
DOM: Traversal-Range
DOM: Abstract Schemas
DOM: Validation
DOM: Views and Formatting
* Rename "DOM: CSSOM" to "DOM CSS Object Model"
* "Document Navigation" from:
Embedding: Docshell
History: Session
* "Layout: Text" from:
Layout: BiDi Hebrew & Arabic
Layout: CTL
Layout: Fonts and Text
* ImageLib -> Image: Decoding
Image: GFX -> Image: Painting
Layout: Images -> Image: Layout
* "XPCOM" from:
XPCOM
XPCOM registry
xpidl
Further comments?
Gerv
Boris Zbarsky
> * dbaron wants to keep the distinctions between the below; bz wants to
> combine them into DOM: Other:
> DOM: Load and Save
> DOM: Traversal-Range
> DOM: Abstract Schemas
> DOM: Validation
> DOM: Views and Formatting
I don't so much _want_ anything here as I am willing to accept combining these
(and I'm not sure dbaron _wanted_ to keep the distinctions between these; did I
miss something?). But "DOM: Load and Save" and "DOM: Views and Formatting" are
very confusing -- the former gets various file handling bugs, the latter gets
layout bugs. Neither gets any bugs that are actually relevant to them, largely
because there are no such bugs: we don't implement Load and Save, and our impl
of Views and Formatting is minimal and covered by the CSSOM component. So we
should at least try some renaming.
-Boris
Gervase Markham
> Gervase Markham wrote:
>> * dbaron wants to keep the distinctions between the below; bz wants to
>> combine them into DOM: Other:
>> DOM: Load and Save
>> DOM: Traversal-Range
>> DOM: Abstract Schemas
>> DOM: Validation
>> DOM: Views and Formatting
>
> I don't so much _want_ anything here as I am willing to accept combining
> these (and I'm not sure dbaron _wanted_ to keep the distinctions between
> these; did I miss something?).
OK; he said "I suspect many of these distintions are useful, although
I'm not sure.", which isn't as strong as I put it.
> But "DOM: Load and Save" and "DOM: Views
> and Formatting" are very confusing -- the former gets various file
> handling bugs, the latter gets layout bugs. Neither gets any bugs that
> are actually relevant to them, largely because there are no such bugs:
> we don't implement Load and Save, and our impl of Views and Formatting
> is minimal and covered by the CSSOM component. So we should at least
> try some renaming.
Or removal/merging.
Proposal: Merge DOM: Views and Formatting into DOM: CSS Object Model,
and remove DOM: Load and Save (throwing any bugs into DOM: Other).
Gerv
Boris Zbarsky
> OK; he said "I suspect many of these distintions are useful, although
> I'm not sure.", which isn't as strong as I put it.
Or as specific to these five components, yeah. ;)
> Proposal: Merge DOM: Views and Formatting into DOM: CSS Object Model,
> and remove DOM: Load and Save (throwing any bugs into DOM: Other).
That sounds reasonable to me.
-Boris
AC
> So, attempting to synthesize these comments and find consensus:
>
> * "DOM to Text Conversion" -> Serializers
>
> * "DOM" from
> DOM
> DOM: Core
> DOM: Level 0
> DOM: HTML
>
> * DOM: Events remains as-is.
>
> * dbaron wants to keep the distinctions between the below; bz wants to
> combine them into DOM: Other:
> DOM: Load and Save
> DOM: Traversal-Range
> DOM: Abstract Schemas
> DOM: Validation
> DOM: Views and Formatting
>
> * Rename "DOM: CSSOM" to "DOM CSS Object Model"
>
> Further comments?
Maybe make clearer name distinction between "DOM" and "DOM: Other" ?
Is "DOM" just about DOM APIs? (Though Traversal sounds like APIs also)
Gervase Markham
> Maybe make clearer name distinction between "DOM" and "DOM: Other" ?
> Is "DOM" just about DOM APIs? (Though Traversal sounds like APIs also)
Someone needs to suggest something.
Gerv
fantasai
Suggestion:
* "DOM: Core" from
DOM
DOM: Core
DOM: Level 0
DOM: HTML
So we have
DOM: Core
DOM: Events
DOM: CSS Object Model
DOM: Other
~fantasai
AC
I found that in the DOM TRs, Core does not include HTML.
http://www.w3.org/DOM/DOMTR
thus suggestion: "DOM" -> "DOM: Core & HTML"