PSA: public/web/ will move to public/{core, modules}/

[Kentaro Hara]

Hi

We removed Source/web/ a few months ago but public/web/ was left as is (*). I got feedback from a couple of people that this is confusing because public/web/XXX.h is implemented by Source/{core, modules}/.../XXX.cpp.

To avoid the confusion, we're planning to create public/{core, modules}/ and move headers in public/web/ to those directories. The end state will be very simple:

- public/core/XXX.h is implemented by Source/core/.

- public/modules/XXX.h is implemented by Source/modules/.

- public/platform/XXX.h is implemented by Source/platform/.

If you have any concern, let me know! :)

(*) We left public/web/ as is because all public APIs were supposed to be gone after Onion Soup 2.0 is done. However, it turned out 1) it will take one or two years to get there and 2) some public APIs will remain even after Onion Soup since //chrome/, //components/ etc still need them. So we decided to make this change before waiting for Onion Soup.

--

Kentaro Hara, Tokyo, Japan

[Yutaka Hirano]

The relationship between public/platform and Source/platform is very different from the (to be) relationship between public/core and Source/core. Isn't it confusing?

--
You received this message because you are subscribed to the Google Groups "blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+unsubscribe@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CABg10jwQu0Vq%2Bf7NiOkXc3_mQ325U%3DYNEygTVEYcro6%2Baq%2B9%2Bg%40mail.gmail.com.

[Kentaro Hara]

> The relationship between public/platform and Source/platform is very different from the (to be) relationship between public/core and Source/core. Isn't it confusing?

Sorry for not being clear.

- public/core/XXX.h is implemented by Source/core/exported/.

- public/modules/XXX.h is implemented by Source/modules/exported/.

- public/platform/XXX.h is implemented by Source/platform/exported/.

Does this make sense?

[Daniel Bratell]

core, modules, platform is mostly a Blink internal organization. Does it make sense to expose that to the world outside Blink? Right now it's mostly a long list of headers of external APIs, and I think it could stay that way even if the folder is no longer named "web".

/Daniel

--
You received this message because you are subscribed to the Google Groups "blink-dev" group.

To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CABg10jwQu0Vq%2Bf7NiOkXc3_mQ325U%3DYNEygTVEYcro6%2Baq%2B9%2Bg%40mail.gmail.com.

--

/* Opera Software, Linköping, Sweden: CET (UTC+1) */

[Kentaro Hara]

> core, modules, platform is mostly a Blink internal organization. Does it make sense to expose that to the world outside Blink?

The long term plan is to remove most of the public APIs through Onion Souping.

> Right now it's mostly a long list of headers of external APIs, and I think it could stay that way even if the folder is no longer named "web".

What name would you suggest?

A frequently asked question is: "What is public/web/? Some headers are implemented by core/exported/, some headers are by modules/exported/... c.f., public/platform/ is implemented by platform/exported/."

On Fri, Nov 17, 2017 at 6:42 PM, Daniel Bratell <bra...@opera.com> wrote:

core, modules, platform is mostly a Blink internal organization. Does it make sense to expose that to the world outside Blink? Right now it's mostly a long list of headers of external APIs, and I think it could stay that way even if the folder is no longer named "web".

/Daniel

On Fri, 17 Nov 2017 05:12:06 +0100, Kentaro Hara <har...@chromium.org> wrote:

Hi

We removed Source/web/ a few months ago but public/web/ was left as is (*). I got feedback from a couple of people that this is confusing because public/web/XXX.h is implemented by Source/{core, modules}/.../XXX.cpp.

To avoid the confusion, we're planning to create public/{core, modules}/ and move headers in public/web/ to those directories. The end state will be very simple:

- public/core/XXX.h is implemented by Source/core/.

- public/modules/XXX.h is implemented by Source/modules/.

- public/platform/XXX.h is implemented by Source/platform/.

If you have any concern, let me know! :)

(*) We left public/web/ as is because all public APIs were supposed to be gone after Onion Soup 2.0 is done. However, it turned out 1) it will take one or two years to get there and 2) some public APIs will remain even after Onion Soup since //chrome/, //components/ etc still need them. So we decided to make this change before waiting for Onion Soup.

--

Kentaro Hara, Tokyo, Japan

--
You received this message because you are subscribed to the Google Groups "blink-dev" group.

To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+unsubscribe@chromium.org.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CABg10jwQu0Vq%2Bf7NiOkXc3_mQ325U%3DYNEygTVEYcro6%2Baq%2B9%2Bg%40mail.gmail.com.

--

/* Opera Software, Linköping, Sweden: CET (UTC+1) */

[Daniel Bratell]

On Fri, 17 Nov 2017 11:39:30 +0100, Kentaro Hara <har...@chromium.org> wrote:

> core, modules, platform is mostly a Blink internal organization. Does it make sense to expose that to the world outside Blink?

The long term plan is to remove most of the public APIs through Onion Souping.

> Right now it's mostly a long list of headers of external APIs, and I think it could stay that way even if the folder is no longer named "web".

What name would you suggest?

A frequently asked question is: "What is public/web/? Some headers are implemented by core/exported/, some headers are by modules/exported/... c.f., public/platform/ is implemented by platform/exported/."

It could be public/includes? The APIs would then sometimes be implemented in Source/platform and sometime in Source/modules and sometimes in Source/core and there would be no obvious way to know where, but maybe that is not a big problem?

/Daniel

[Kentaro Hara]

public/platform/ should be separated from public/{core,modules}/ because the layering (and the dependency constraint) is different.

- public/{core,modules}/ is a set of APIs that are implemented by Blink and used by Chromium.

- public/platform/ is a set of APIs that are implemented by Chromium and used by Blink.

Mixing the two APIs in one directory would be more confusing.

Note: Today there are a lot of APIs violating the rule (e.g., people use public/platform/ just because it's convenient). This will be fixed through Onion Souping :)

[Daniel Bratell]

On Fri, 17 Nov 2017 13:56:12 +0100, Kentaro Hara <har...@chromium.org> wrote:

public/platform/ should be separated from public/{core,modules}/ because the layering (and the dependency constraint) is different.

- public/{core,modules}/ is a set of APIs that are implemented by Blink and used by Chromium.

- public/platform/ is a set of APIs that are implemented by Chromium and used by Blink.

Mixing the two APIs in one directory would be more confusing.

Note: Today there are a lot of APIs violating the rule (e.g., people use public/platform/ just because it's convenient). This will be fixed through Onion Souping :)

Could be public/includes for {core, modules}, and public/interfaces for platform, but I have no strong feelings here. I just want the names to primarily be good for people outside Blink since they make up Blink's public surface.

[Stuart Langley]

It makes sense to me that users of the APIs should not really care if they are implemented in core/ or modules/, and we should try and keep this implementation detail as internal as possible.

Updating public/web to public/includes seems reasonable, especially when we consider that the end state of the onion soup project will remove many of these public headers entirely.

haraken@ - WDYT of just changing public/web -> public/includes ?

--

You received this message because you are subscribed to the Google Groups "blink-dev" group.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/op.y9unojyprbppqq%40cicero2.linkoping.osa.

[Kentaro Hara]

On Mon, Nov 20, 2017 at 12:09 PM, Stuart Langley <slan...@chromium.org> wrote:

It makes sense to me that users of the APIs should not really care if they are implemented in core/ or modules/, and we should try and keep this implementation detail as internal as possible.

Fair enough :)

Updating public/web to public/includes seems reasonable, especially when we consider that the end state of the onion soup project will remove many of these public headers entirely.

haraken@ - WDYT of just changing public/web -> public/includes ?

Then I'd prefer just adding a very good comment on public/web/ though. Just renaming the directory won't help a lot :/

Another option would be:

- Keep public/web/ as is.

- Move public/platform/XXX.h implemented by Blink to public/web/.

Then we will have the following state:

- public/platform/XXX.h is implemented by Chromium and used by Blink.

- public/web/XXX.h is implemented by Blink and used by Chromium.

Nit: If we want to rename public/web/ to something, I'd vote on public/exported/ (because it's implemented by Source/{core,modules,platform}/exported/).

 

On Sat, Nov 18, 2017 at 12:27 AM, Daniel Bratell <bra...@opera.com> wrote:

On Fri, 17 Nov 2017 13:56:12 +0100, Kentaro Hara <har...@chromium.org> wrote:

public/platform/ should be separated from public/{core,modules}/ because the layering (and the dependency constraint) is different.

- public/{core,modules}/ is a set of APIs that are implemented by Blink and used by Chromium.

- public/platform/ is a set of APIs that are implemented by Chromium and used by Blink.

Mixing the two APIs in one directory would be more confusing.

Note: Today there are a lot of APIs violating the rule (e.g., people use public/platform/ just because it's convenient). This will be fixed through Onion Souping :)

Could be public/includes for {core, modules}, and public/interfaces for platform, but I have no strong feelings here. I just want the names to primarily be good for people outside Blink since they make up Blink's public surface.

/Daniel

--

/* Opera Software, Linköping, Sweden: CET (UTC+1) */

--
You received this message because you are subscribed to the Google Groups "blink-dev" group.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/op.y9unojyprbppqq%40cicero2.linkoping.osa.

[Stuart Langley]

How about we add a README.md to public/web and then leave it as is until we complete onion soup, which will remove a bunch of these files. 

Then we can make a good decision about what to do with the bits that are left.

[Kentaro Hara]

How about we add a README.md to public/web and then leave it as is until we complete onion soup, which will remove a bunch of these files. 

+1!

[Victor Costan]

On Sun, Nov 19, 2017 at 7:46 PM, Kentaro Hara <har...@chromium.org> wrote:

On Mon, Nov 20, 2017 at 12:09 PM, Stuart Langley <slan...@chromium.org> wrote:

It makes sense to me that users of the APIs should not really care if they are implemented in core/ or modules/, and we should try and keep this implementation detail as internal as possible.

Fair enough :)

Updating public/web to public/includes seems reasonable, especially when we consider that the end state of the onion soup project will remove many of these public headers entirely.

haraken@ - WDYT of just changing public/web -> public/includes ?

Then I'd prefer just adding a very good comment on public/web/ though. Just renaming the directory won't help a lot :/

Another option would be:

- Keep public/web/ as is.

- Move public/platform/XXX.h implemented by Blink to public/web/.

Then we will have the following state:

- public/platform/XXX.h is implemented by Chromium and used by Blink.

- public/web/XXX.h is implemented by Blink and used by Chromium.

I think it would be really nice if we could explain where everything is using a small set of rules like the ones described above.

Thank you,

    Victor