Migrate web-platform features in content/ into Blink

[Yuki Shiino]

Hi team,

I had a talk about how to migrate web-platform features in content/{child,renderer}/ to third_party/WebKit/ using Mojo in Blink.  Let me introduce the deck of slides here.

https://docs.google.com/presentation/d/1HAzSSlLqcMl7TsJFqhy-gXx4TfsAygOLfm7aOY7DoU4/edit?usp=sharing

Also there is a list of web-platform features that should be migrated from content/ to third_party/WebKit/.  If you're interested in the migration, we're more than happy to help you guys.

https://docs.google.com/spreadsheets/d/1VIINt17Dg2cJjPpoJ_HY3HI0uLpidql-1u8pBJtpbGk/edit?usp=sharing

Cheers,

Yuki Shiino

[Kentaro Hara]

I created a tracking bug here.

yukishiino@ already moved BatteryStatus. rouslan@ is working on PaymentRequest. sammc@ is working on GeoLocation.

We welcome your contributions!

--

Kentaro Hara, Tokyo, Japan

[Ken Rockot]

Also note that ortuno@ is now beginning the process of moving Web Bluetooth.

[Reilly Grant]

reillyg@ (that's me) will be moving WebUSB as soon as Mojo bindings can be used directly from Source/modules. This is as I understand it blocked on Mojo bindings using WTF types instead of STL types and will be available soon.

[Harald Alvestrand]

Is there a design guideline for what should be in blink vs what should be in content?

So far, the divisions I've seen have been more practical than principled - if it's easier to program with std:: types, such as when talking directly to IPC mechanisms, keep it in content/ - if it's simpler to deal with WebString and WebVector, keep it in blink.

That doesn't seem like a sensible basis for an architectural split.

--
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.

[Kentaro Hara]

On Sat, Mar 12, 2016 at 12:13 AM, Harald Alvestrand <h...@google.com> wrote:

Is there a design guideline for what should be in blink vs what should be in content?

So far, the divisions I've seen have been more practical than principled - if it's easier to program with std:: types, such as when talking directly to IPC mechanisms, keep it in content/ - if it's simpler to deal with WebString and WebVector, keep it in blink.

That doesn't seem like a sensible basis for an architectural split.

The principle is that all web-platform features in content/{child,renderer} should be moved to blink's platform/.

Currently we're implementing a converter between WTF types (WTF::String, WTF::Vector, WTF::HashMap etc) and Mojo types. Once the converter is available, blink's platform/ can directly talk with Mojo. Then WebString and WebVector are not needed. Also our plan is to convert the old IPC in content/ to Mojo before doing the migration (instead of supporting the old IPC in blink's platform/).

 

On Thu, Mar 10, 2016 at 4:44 PM, Reilly Grant <rei...@chromium.org> wrote:

reillyg@ (that's me) will be moving WebUSB as soon as Mojo bindings can be used directly from Source/modules. This is as I understand it blocked on Mojo bindings using WTF types instead of STL types and will be available soon.

On Wed, Mar 9, 2016, 22:38 Ken Rockot <roc...@chromium.org> wrote:

Also note that ortuno@ is now beginning the process of moving Web Bluetooth.

On Wed, Mar 9, 2016 at 10:36 PM, Kentaro Hara <har...@chromium.org> wrote:

I created a tracking bug here.

yukishiino@ already moved BatteryStatus. rouslan@ is working on PaymentRequest. sammc@ is working on GeoLocation.

We welcome your contributions!

On Thu, Mar 10, 2016 at 11:01 AM, Yuki Shiino <yukis...@chromium.org> wrote:

Hi team,

I had a talk about how to migrate web-platform features in content/{child,renderer}/ to third_party/WebKit/ using Mojo in Blink.  Let me introduce the deck of slides here.

https://docs.google.com/presentation/d/1HAzSSlLqcMl7TsJFqhy-gXx4TfsAygOLfm7aOY7DoU4/edit?usp=sharing

Also there is a list of web-platform features that should be migrated from content/ to third_party/WebKit/.  If you're interested in the migration, we're more than happy to help you guys.

https://docs.google.com/spreadsheets/d/1VIINt17Dg2cJjPpoJ_HY3HI0uLpidql-1u8pBJtpbGk/edit?usp=sharing

Cheers,

Yuki Shiino

--

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+...@chromium.org.

[Harald Alvestrand]

On Fri, Mar 11, 2016 at 4:38 PM, Kentaro Hara <har...@chromium.org> wrote:

On Sat, Mar 12, 2016 at 12:13 AM, Harald Alvestrand <h...@google.com> wrote:

Is there a design guideline for what should be in blink vs what should be in content?

So far, the divisions I've seen have been more practical than principled - if it's easier to program with std:: types, such as when talking directly to IPC mechanisms, keep it in content/ - if it's simpler to deal with WebString and WebVector, keep it in blink.

That doesn't seem like a sensible basis for an architectural split.

The principle is that all web-platform features in content/{child,renderer} should be moved to blink's platform/.

Sorry for being totally dense, but where's the limit between "is a web-platform feature" and "not a web-platform feature"?

ie is the end game for this process "move content/ into blink", and if not, what's left?

[Kentaro Hara]

This is a list I'm now thinking about. Does it make sense?

[Dirk Pranke]

+esprehn, +jam explicitly, who can maybe help correct/clarify what's going on, at least if I say something stupid.

I will say up front that I've been too distracted by the GN migration and other things to have been paying much attention to this work, and I haven't seen the Onion Soup talks, so I'm probably way late to this discussion, but ...

When I asked about this a bit at the Brown Bag on Wednesday (where we talked about this topic), it seemed like we were just talking about the glue (client) code in content/renderer for the different services moving to blink/platform, but the implementation of the services (which often live in the browser process or elsewhere) don't move. 

Is this paragraph a more accurate description of what's going on? Even then, it seems like if we need to move any glue/client code into blink/platform code at all the mojo-ification of things isn't really doing what I thought it would do, but maybe I'm still missing some things.

I certainly don't think we should put *all* of the code for every feature in the web platform into blink/platform. For starters, much of the implementation of services like IndexedDB lives in the browser process, right? But I don't think that's what we're actually planning to do?

-- Dirk

[Miguel Casas]

Some of the "file globs" use IPC. Is the idea to first migrate the browser-renderer to Mojo and, in another step, migrate the renderer/child side to Platform? Or the other way around...?

--

Miguel Casas-Sanchez |

Gatopardo del Software |

ydog / mca...@google.com |

+1 (650) 603 1380

[Elliott Sprehn]

On Fri, Mar 11, 2016 at 9:51 AM, Dirk Pranke <dpr...@chromium.org> wrote:

+esprehn, +jam explicitly, who can maybe help correct/clarify what's going on, at least if I say something stupid.

I will say up front that I've been too distracted by the GN migration and other things to have been paying much attention to this work, and I haven't seen the Onion Soup talks, so I'm probably way late to this discussion, but ...

When I asked about this a bit at the Brown Bag on Wednesday (where we talked about this topic), it seemed like we were just talking about the glue (client) code in content/renderer for the different services moving to blink/platform, but the implementation of the services (which often live in the browser process or elsewhere) don't move. 

Is this paragraph a more accurate description of what's going on? Even then, it seems like if we need to move any glue/client code into blink/platform code at all the mojo-ification of things isn't really doing what I thought it would do, but maybe I'm still missing some things.

I certainly don't think we should put *all* of the code for every feature in the web platform into blink/platform. For starters, much of the implementation of services like IndexedDB lives in the browser process, right? But I don't think that's what we're actually planning to do?

The current plan is that content/browser will not move, but will include the mojoms from the blink public API probably. So content/browser/bluetooth includes third_party/WebKit/public/platform/modules/bluetooth.mojom

Your service implementation doesn't need to live in blink, but the blink API is going to get much higher level, so you're not going to be able to implement a service in content/ that uses ex. WebNode.

- E

[Joshua Bell]

On Fri, Mar 11, 2016 at 2:15 PM, 'Miguel Casas' via blink-dev <blin...@chromium.org> wrote:

Some of the "file globs" use IPC.

FWIW, I added the "(or file glob)" bit, since some logical modules don't have a dedicated subdirectory in renderer/child. IMHO, those are particularly attractive targets for moving to Blink+Mojo since they have such little footprint in renderer/child other than as an IPC proxy for Blink.

 

Is the idea to first migrate the browser-renderer to Mojo and, in another step, migrate the renderer/child side to Platform? Or the other way around...?

Why break it into two steps?

[Kentaro Hara]

I'm happy that many contributors have been working on Blink-with-Mojo. Many modules/ features such as Payment, Vibration, MediaStream, Bluetooth etc are already migrated to Mojo. I hope that all modules/ features are migrated to Mojo at some point :)

If you want to work on Blink-with-Mojo, just add your name to this sheet and update the status.

Thanks!