In order to make our codebase more accessible, I'm planning on doing some reorganizations of source files. Here is my plan for content/ and dom/. jst has looked it over, but I'd like to post it publicly before beginning to implement it:
1) put everything under dom/
2) Keep the public IDL interfaces in roughly their current form in dom/interfaces
3) Use the following other directories:
dom/base (nsIDocument/nsIContent, as well as parts of content/base/{public,src}) dom/window (nsGlobalWindow stuff currently in dom/src/base) dom/events (including stuff currently in dom/src/events and content/events) dom/geolocation dom/json dom/jsurl dom/offline dom/storage dom/threads dom/html dom/html/canvas dom/html/media dom/mathml dom/svg dom/svg/smil dom/xbl dom/xml dom/xslt dom/xtf dom/xul
Within these directories, avoid public/ and src/. In some cases I might keep some subdirectories such as dom/xul/tree or dom/xul/templates to keep the size of the directory manageable.
4) as a second step after the moves, stop exporting lots of internal headers to dist/include. I think we probably need to keep exporting nsIDocument/nsIContent, but avoid all the implementation headers.
I'm going to be doing this in small-ish pieces, for ease of testing/review. `hg revert` doesn't un-do file moves correctly, so backing these changes out after they have landed will be difficult and I'd like to avoid it if possible.
What effect will this have on moving changesets from m-c to mozilla-1.9.1 after they've baked? I'm a little worried about adding extra hassle or risk to that process at this stage in the schedule, I admit.
Mike
On 1/20/09, Benjamin Smedberg <benja...@smedbergs.us> wrote:
> In order to make our codebase more accessible, I'm planning on doing some > reorganizations of source files. Here is my plan for content/ and dom/. jst > has looked it over, but I'd like to post it publicly before beginning to > implement it:
> 1) put everything under dom/
> 2) Keep the public IDL interfaces in roughly their current form in > dom/interfaces
> 3) Use the following other directories:
> dom/base (nsIDocument/nsIContent, as well as parts of > content/base/{public,src}) > dom/window (nsGlobalWindow stuff currently in dom/src/base) > dom/events (including stuff currently in dom/src/events and content/events) > dom/geolocation > dom/json > dom/jsurl > dom/offline > dom/storage > dom/threads > dom/html > dom/html/canvas > dom/html/media > dom/mathml > dom/svg > dom/svg/smil > dom/xbl > dom/xml > dom/xslt > dom/xtf > dom/xul
> Within these directories, avoid public/ and src/. In some cases I might keep > some subdirectories such as dom/xul/tree or dom/xul/templates to keep the > size of the directory manageable.
> 4) as a second step after the moves, stop exporting lots of internal headers > to dist/include. I think we probably need to keep exporting > nsIDocument/nsIContent, but avoid all the implementation headers.
> I'm going to be doing this in small-ish pieces, for ease of testing/review. > `hg revert` doesn't un-do file moves correctly, so backing these changes out > after they have landed will be difficult and I'd like to avoid it if > possible.
> What effect will this have on moving changesets from m-c to > mozilla-1.9.1 after they've baked? I'm a little worried about adding > extra hassle or risk to that process at this stage in the schedule, I > admit.
You won't be able to use automatic techniques such as `hg export rev | hg import -`, due to misapplied patches.
You will be able to use MQ to rebase trunk->branch.
hg up trunkrev hg qimport -r. hg qsave -e -c hg up -C branchtip hg qpush -m
You can also just use `patch` and type the old filename.
The outstanding set of patches *looks* relatively small to me; I want to catch the sweet spot where there I'm not significantly disrupting branch work, but also not disrupting other big changes that might in the works on trunk.
dom/offline is currently only one source file, and isn't likely to grow (with the possible exception of moving nsOfflineCacheUpdate in there).
dom/storage might get bigger if we end up adding an html5 sql implementation. Maybe we could just move dom/offline in there for now (although I guess they're not particularly related).
>> 2) Keep the public IDL interfaces in roughly their current form in >> dom/interfaces
> I don't feel strongly about this, I suspect it'd also be ok to merge a > bit more heavily here.
> There's also the question of what should live in dom/interfaces, vs. > dom/X/src
>> 3) Use the following other directories:
<...>
> I'm assuming we'll still have the
> dom/X/src > dom/X/tests > dom/X/locales (or maybe just dom/locales?) > dom/X/res (or maybe just dom/res?)
> structure? But move everything in /public into /src? Or are we putting > all the source files in dom/X and the tests in dom/X/tests?
We should only have dom/locales/en-US. That shouldn't be a problem, as content doesn't have l10n files right now, anyway. I might just make it more obvious to look for them in dom/locales ;-)
Axel
PS: My former XSLT-me doesn't have any opinions on this.
> I can merge either/both of these with dom/window
Hmm.. why this facination with dom/window? I would have expected that it would only do the window objects, and maybe a couple supporting dom-level-0 objects like window.location and window.navigator?
>> I'm assuming we'll still have the
>> dom/X/src >> dom/X/tests >> dom/X/locales (or maybe just dom/locales?) >> dom/X/res (or maybe just dom/res?)
>> structure? But move everything in /public into /src? Or are we putting >> all the source files in dom/X and the tests in dom/X/tests?
> I'm merging, so there will not be separate public/ or src/ directories. I > will keep the tests/ separate.
Ok, so the structure will be something like:
dom/X/ (cpp, h and idl files go in here) dom/X/tests/ (mochitests, crashtests, reftests go in here) dom/locales/en-US/ dom/res/
>> I can merge either/both of these with dom/window
> Hmm.. why this facination with dom/window? I would have expected that it > would only do the window objects, and maybe a couple supporting > dom-level-0 objects like window.location and window.navigator?
Also because it is a global property off the DOM window object. I think dom/base should be shared code for nodes/documents or utility code.
> Ok, so the structure will be something like:
> dom/X/ (cpp, h and idl files go in here) > dom/X/tests/ (mochitests, crashtests, reftests go in here) > dom/locales/en-US/
Yes.
> dom/res/
Not sure I want to keep res/... I think the resources will probably live with the code that uses them. But I haven't dealt with any of these yet.
Benjamin Smedberg wrote: > On 1/22/09 6:24 PM, Jonas Sicking wrote: >> Benjamin Smedberg wrote: >>> On 1/20/09 7:38 PM, Jonas Sicking wrote:
>>>>> 3) Use the following other directories: >>>> Don't really think the following deserve their own directories
>>>> dom/json >>> I can merge this into dom/window >> Why dom/window? It's not window related at all. I'd say dom/base
> It is a property of the DOM window object.
>>>> dom/offline (don't feel strongly here) >>>> dom/storage (don't feel strongly here either) >>> I can merge either/both of these with dom/window >> Hmm.. why this facination with dom/window? I would have expected that it >> would only do the window objects, and maybe a couple supporting >> dom-level-0 objects like window.location and window.navigator?
> Also because it is a global property off the DOM window object. I think > dom/base should be shared code for nodes/documents or utility code.
The fact that these are properties of the Window object is a function of that many moons ago the window object was chosen as the global object, it's not because they have anything to do with the window.
What we could do is name the directory something like "dom/api(s)" where we put stuff like window, history, JSON, XMLHttpRequest, treewalker and nodeiterator.
However I'm not convinced we need to split this from dom/base. Splitting too much is what got us to where we are now.
Jonas Sicking wrote: > Benjamin Smedberg wrote: >> On 1/22/09 6:24 PM, Jonas Sicking wrote: >>> Benjamin Smedberg wrote: >>>> On 1/20/09 7:38 PM, Jonas Sicking wrote:
>>>>>> 3) Use the following other directories: >>>>> Don't really think the following deserve their own directories
>>>>> dom/json >>>> I can merge this into dom/window >>> Why dom/window? It's not window related at all. I'd say dom/base
>> It is a property of the DOM window object.
Everything is a property of the DOM window object, one could argue.
I'm with Jonas here, let's keep the window directory more or less what it is today (DOM level 0 goo), and put things that don't really belong anywhere else in dom/base.
Johnny Stenback wrote: > Jonas Sicking wrote: >> Benjamin Smedberg wrote: >>> On 1/22/09 6:24 PM, Jonas Sicking wrote: >>>> Benjamin Smedberg wrote: >>>>> On 1/20/09 7:38 PM, Jonas Sicking wrote:
>>>>>>> 3) Use the following other directories: >>>>>> Don't really think the following deserve their own directories
>>>>>> dom/json >>>>> I can merge this into dom/window >>>> Why dom/window? It's not window related at all. I'd say dom/base
>>> It is a property of the DOM window object.
> Everything is a property of the DOM window object, one could argue.
> I'm with Jonas here, let's keep the window directory more or less what > it is today (DOM level 0 goo), and put things that don't really belong > anywhere else in dom/base.
Or simply collapse everything into dom/base. Doesn't look like it'll be too many files. If it does a few months/years down the road we can always move things again then.
|
