Re: dom/ and content/ source reorganization

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 <[email protected]> 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.
>
> --BDS
> _______________________________________________
> dev-tech-dom mailing list
> [email protected]
> https://lists.mozilla.org/listinfo/dev-tech-dom
>

-- 
Sent from Gmail for mobile | mobile.google.com