Rename src/webkit? (was: Re: [chromium-dev] Please don't override OWNERS checks other than for reverts/file moves/code renames)

[Adam Barth]

Somewhat as an aside, can we rename src/webkit? It's confusing to
have both src/webkit and src/third_party/WebKit, especially when the
former isn't WebKit at all!

Adam

On Tue, Jun 21, 2011 at 3:48 PM, John Abd-El-Malek
<jabde...@google.com> wrote:
> I have added a diagram, plus a brain dump of why content exists, and what
> belongs in it,
> at https://sites.google.com/a/chromium.org/dev/developers/content-module
> On Mon, Jun 13, 2011 at 11:29 AM, Ben Goodger (Google) <b...@chromium.org>
> wrote:
>>
>> On Thu, Jun 9, 2011 at 11:34 PM, Paweł Hajdan, Jr.
>> <phajd...@chromium.org> wrote:
>>>
>>> Ouch, that's bad (it seems that the authors didn't know at all why we
>>> have DEPS files). Maybe we should add some comment to each DEPS file why it
>>> is there, possibly with a link to some article with more details?
>>
>> It'd be great if we could have a diagram showing a generalization of the
>> layering of Chrome code. It would be simple enough to fit in one screenful
>> at the start, but you could then click to zoom in and see more detail on
>> dependencies, with explanations potentially of what the roles were.
>> I understand documentation is usually best when it lives in the code, but
>> I suspect at this point a sizable chunk of the people on the project don't
>> even understand some of the bigger picture conceptual layers in Chrome, and
>> this is the kind of thing best served by a meta diagram.
>>
>> -Ben
>
> --
> Chromium Developers mailing list: chromi...@chromium.org
> View archives, change email options, or unsubscribe:
> http://groups.google.com/a/chromium.org/group/chromium-dev
>

[Darin Fisher]

Yes, please!  I've long wanted to rename it, but I've struggled to find a good name.

We may also consider exploding it a bit or at least re-organizing it.  It needs help!

webkit/ contains a couple interesting directories:

  glue/  -  helpers for using the WebKit API.  contains structures that resemble

WebKit API types, but the structures can be serialized over IPC.

  support/  - helpers for enabling DRT and test_shell that Chrome doesn't need.

A good bit of the code under tools/test_shell/ should actually move here.

  plugins/  - contains in-proc implementations of NPAPI and Pepper plugin

hosting code.  This is independent of WebKit, and could live elsewhere, but

we do need to use it from DRT (so we can run plugin layout tests).

  appcache/, blob/, database/, fileapi/, quota/  - contains chromium specific

backends for some of these WebCore features, built using chromium code

(e.g., appcache depends on the chromium network stack's disk cache).

  gpu/  - similar in spirit to support/, but only for GPU stuff.

  mocks/  - mocks for WebKit API interfaces.

  tools/, data/  - blah, blah

-Darin

[Dirk Pranke]

Maybe something like either webkit_api or web_platform ?

-- Dirk

[Levi Weintraub]

I'd say webkit_support, but then I'd also have to come up for a name for the support directory underneath.

[Adam Barth]

Yeah, or just "platform".

-> chrome
-> content
-> platform
-> base

Adam

On Tue, Jun 21, 2011 at 4:04 PM, Dirk Pranke <dpr...@chromium.org> wrote:

[Ben Goodger (Google)]

Sounds a little generic. What platform, exactly? :-)

-Ben

[Albert J. Wong (王重傑)]

bridge?

[Adam Barth]

You know, the one Chrome presents to the world: the web platform. :)

Adam

[Ben Goodger (Google)]

Yes, but we use more platform pieces within Chrome than just Webkit.

Please choose a more specific name.

-Ben

[Michael Nordman]

web_platform is pretty good for some of the stuff in there

[Darin Fisher]

Yeah, I contemplated that name a bunch.  It just feels a bit too inclusive / over-arching.  Most of what it is src/webkit/ is really just supporting material.

One idea would be to recast src/webkit/ as a subdirectory of src/content/, since some portions of it could be viewed as implementation details of src/content/.  The main reason NOT to do that is because src/webkit/ also contains the things you need to support DRT, whereas src/content/ has way more than what DRT requires.

-Darin

[Adam Barth]

On Wed, Jun 22, 2011 at 10:35 AM, Darin Fisher <da...@google.com> wrote:
> Yeah, I contemplated that name a bunch.  It just feels a bit too inclusive /
> over-arching.  Most of what it is src/webkit/ is really just supporting
> material.

It seems like the folder has too much different stuff in it, which
might be profitable to separate:

Our implementations of some parts of WebCore/platform:
appcache/
blob/
database/
chromeos/
fileapi/
gpu/

=> Move to src/webcore_platform/

Our WebKit client:
glue/
build/ <-- Just one file
quota/ <-- Not 100% sure about this one

=> Move to src/webkit_client/

plugins/ <-- Note sure why this is separate from glue, but if we
want to keep it separate, we could move it to src/plugins/

Embeddings of WebKit for testing (plus supporting infrastructure):
default_plugin/
mocks/
support/
tools/

=> Move to src/webkit_client/test/

Unsure:
extensions/v8/

(I would also split up the WebKit API into two pieces, the platform
and the client piece, but that's another topic.)

> One idea would be to recast src/webkit/ as a subdirectory of src/content/,
> since some portions of it could be viewed as implementation details of
> src/content/.  The main reason NOT to do that is because src/webkit/ also
> contains the things you need to support DRT, whereas src/content/ has way
> more than what DRT requires.

Right, if we did that, we'd lose the uniprocess embedding layer.

chrome -> The specific multi-process browser we ship.
content -> A multi-process browser.
webkit_client -> A uniprocess embedding of WebKit.
third_party/WebKit -> A library for rendering web pages.
webcore_platform -> A library used by third_party/WebKit
base -> (etc)

[Darin Fisher]

On Wed, Jun 22, 2011 at 11:04 AM, Adam Barth <aba...@chromium.org> wrote:

On Wed, Jun 22, 2011 at 10:35 AM, Darin Fisher <da...@google.com> wrote:
> Yeah, I contemplated that name a bunch.  It just feels a bit too inclusive /
> over-arching.  Most of what it is src/webkit/ is really just supporting
> material.

It seems like the folder has too much different stuff in it, which
might be profitable to separate:

Our implementations of some parts of WebCore/platform:
 appcache/
 blob/
 database/
 chromeos/
 fileapi/
 gpu/

=> Move to src/webcore_platform/

Our WebKit client:
 glue/
 build/ <-- Just one file
 quota/  <-- Not 100% sure about this one

It might be clearer to call this webkit_platform/, as most likely that is how

we would refer to the set of WebKit API interfaces it implements.  To your

point below, I suspect WebKitClient should be renamed WebKitPlatform.

 

=> Move to src/webkit_client/

"webkit_client" is an interesting idea for this directory.  I'm not 100% sold

on it yet, but I like the way you are thinking about this.

 

 plugins/  <-- Note sure why this is separate from glue, but if we
want to keep it separate, we could move it to src/plugins/

Embeddings of WebKit for testing (plus supporting infrastructure):
 default_plugin/
 mocks/
 support/
 tools/

=> Move to src/webkit_client/test/

Unsure:
 extensions/v8/

(I would also split up the WebKit API into two pieces, the platform
and the client piece, but that's another topic.)

^^^ Yes, I'd like to see WebKit API split along those lines too.

[Darin Fisher]

Ohhh... how about this?  In some sense the unifying idea of src/webkit/ is that it

contains stuff that supports WebKit.  It supports WebKit both literally in terms of

providing platform support, and it also supports embedding clients of WebKit.

How about:

webkit_support/

  platform/

    blob/

    database/

    fileapi/

    test/

    ...

  client/

    test/

One top-level directory is better than two!

Another issue:  We have test specific code both at the platform level and the client level.

You can see that I put a test/ folder in each.

-Darin

[Adam Barth]

That sounds good. It's also easier to understand as an abstraction
for folks who don't interact with WebKit much.

Adam

[Dirk Pranke]

works for me.

[Michael Nordman]

sgtm...

fyi, the 'quota' directory belongs next to fileapi, database, appcache, it's the uniifed quota management system for those things.

On Wed, Jun 22, 2011 at 11:14 AM, Darin Fisher <da...@chromium.org> wrote:

[Adam Barth]

In the short term, the easiest thing to do is probably just rename
src/webkit to src/webkit_support. We can tackle the internal
re-organization of the directory in the next iteration. (I'm happy to
take care of the first iteration if no one else is excited about doing
it.)

Adam

[Dirk Pranke]

Note that the bots (and people) depend on the scripts in
webkit/tools/layout_tests, so we'll need to update people and/or warn
them when we do the rename.

It would be nice if we could put the scripts somewhere more obvious,
maybe src/tools? They're only wrappers around the scripts in the
webkit repo anyway.

-- Dirk