Loading hyphenation dictionaries in Blink

[Koji Ishii]

Hi platform-architecture-dev@,

I'm investigating how to load hyphenation dictionaries in Blink.

• In Android, files are located in "/system/usr/hyphen-data". The raw content is passed to hyphenation code in Minikin, a piece of code we're importing from Android.
• We may extend this to Win/Linux by downloading dictionaries, but the plan isn't finalized yet.
  
• Mac has system API so we won't do this.

By reading "Blink in Mojo" presentation, I suppose it's recommended to use mojo.

Advises appreciated if my understanding are correct:

1. What is the current recomended directory to place files? The presentation says "WebKit/Source/platform/<name>" but it no longer exists.
1. mojom files
2. Impl code to run in browser process (to read files)
2. What is the best way to share read-only file content across process? I saw mojo::SharedBuffer. It looks like I can allocate a buffer and read the file into it, but ideally I'd like to mmap and share it.
• Android has system-wide shared mmap, but it's not exposed. We'll need to find the file, open, and mmap by ourselves.
  

Thank you for your support in advance.

/koji

[Kentaro Hara]

+Elliott

--
You received this message because you are subscribed to the Google Groups "platform-architecture-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to platform-architect...@chromium.org.
To post to this group, send email to platform-arc...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/platform-architecture-dev/CACQRE%2BS3qVfGKu5goGKE1zL0WZFxPdwXkLSD80CE4-6erd3SLA%40mail.gmail.com.

--

Kentaro Hara, Tokyo, Japan

[Jochen Eisinger]

Usually we transfer a read only file descriptor and mmap that in the child process.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/platform-architecture-dev/CABg10jyHVWar_jAkPQ7GQ3y409VWFvT7b4eoqj2Rx8ypaYRsRQ%40mail.gmail.com.

[Koji Ishii]

On Wed, Jun 29, 2016 at 3:07 PM, Jochen Eisinger <joc...@chromium.org> wrote:

Usually we transfer a read only file descriptor and mmap that in the child process.

​Thank you Jochen for the reply. I understand we did this in old IPC, is it the same in mojo? More specifically:

• Can mojo use PlatformFileForTransit to transmit file descriptor across process, or is there something alternative to handle file descriptor?
  
• If I were to  use PlatformFileForTransit , I'll need to do it in 2 steps; a) browser to open file descriptor, and b) content/renderer to mmap to give it to blink-platform (because platform cannot use base::file to mmap IIUC) correct?

This (browser <-> content/render <-> platform) looked like opposite from mojo in Blink presentation to me, which motivated me to ask here, but I might misunderstand somewhere.

/koji

[Elliott Sprehn]

You shouldn't need to involve content at all. Platform and WTF can both depend on components/ (for self contained components that don't depend on content or blink) or on base/.

I think you just want to pass the file descriptor through mojo. I'm pretty sure that should work. I think that's what mojo is doing to pass around pipes under the hood anyway.

[Anand K. Mistry]

On 29 June 2016 at 16:43, Elliott Sprehn <esp...@chromium.org> wrote:

You shouldn't need to involve content at all. Platform and WTF can both depend on components/ (for self contained components that don't depend on content or blink) or on base/.

I think you just want to pass the file descriptor through mojo. I'm pretty sure that should work. I think that's what mojo is doing to pass around pipes under the hood anyway.

On Jun 28, 2016 11:35 PM, "Koji Ishii" <ko...@chromium.org> wrote:

On Wed, Jun 29, 2016 at 3:07 PM, Jochen Eisinger <joc...@chromium.org> wrote:

Usually we transfer a read only file descriptor and mmap that in the child process.

​Thank you Jochen for the reply. I understand we did this in old IPC, is it the same in mojo? More specifically:

• Can mojo use PlatformFileForTransit to transmit file descriptor across process, or is there something alternative to handle file descriptor?

In Mojo, we use mojo::WrapPlatformFile and mojo::UnwrapPlatformFile to transfer file descriptors. In the .mojom file, you declare the type as "handle" and use those functions to convert between fds and Mojo handles.

• 
  
• If I were to  use PlatformFileForTransit , I'll need to do it in 2 steps; a) browser to open file descriptor, and b) content/renderer to mmap to give it to blink-platform (because platform cannot use base::file to mmap IIUC) correct?

This (browser <-> content/render <-> platform) looked like opposite from mojo in Blink presentation to me, which motivated me to ask here, but I might misunderstand somewhere.

/koji

--
You received this message because you are subscribed to the Google Groups "platform-architecture-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to platform-architect...@chromium.org.
To post to this group, send email to platform-arc...@chromium.org.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/platform-architecture-dev/CAO9Q3iKbvCQKJEGdz1OGKu%3DQyxtffb_NCfXDdu8SOC-RYUvFMw%40mail.gmail.com.

[Koji Ishii]

Thank you, so IIUC:

1. src/component/<name> to contain:
1. mojom
2. File open code to run in browser process, return using mojo::WrapPlatformFile
2. platform/fonts to contain:
1. connectToRemoteService() to connect to the component
   
2. mojo::UnwrapPlatformFile to get the file descriptor and base::File to mmap
   

Haven't coded these yet but I'll look around samples and try this.

/koji

[Koji Ishii]

In the review of the CL, two reviewers prefer having the code in "content/browser/renderer_host/" rather than in "components/". Please refer to my comment #15.

I don't have strong opinions, nor enough knowledge for outside Blink to prefer either way, but appreciate inputs if any, either here or in the CL. I will follow the two reviewers if not.

/koji

[Jochen Eisinger]

Some background on this: components/ became a bit of a dumping ground, so we're trying to limit new components to things that are shared with iOS, or are so big that they warrant their own component, like eg arc++.

You can put the hyphenation code into its own subdirectory in content/{browser,renderer} and use DEPS to limit what it can include.

[Brett Wilson]

On Sat, Jul 9, 2016 at 3:02 AM, Jochen Eisinger <joc...@chromium.org> wrote:

Some background on this: components/ became a bit of a dumping ground, so we're trying to limit new components to things that are shared with iOS, or are so big that they warrant their own component, like eg arc++.

You can put the hyphenation code into its own subdirectory in content/{browser,renderer} and use DEPS to limit what it can include.

+1. If your code is used by component "foo" and things above "foo" in the dependency tree, your code should probably live in "foo". The components directory was created mainly to share code between iOS Chrome and other versions which otherwise have little-to-no common code outside of base.

If you do this, it's great to still think of your code like a "component" that has a separate directory, doesn't depend on other things in that module, has BUILD and DEPS file to control how it interacts with the outside world.

Brett

[Koji Ishii]

Thank you for the detailed background, very helpful to learn. I will upload the updated CL soon.

/koji

[Elliott Sprehn]

Please don't add more code to content/renderer though, you want your code in blink itself and just using Mojo IPC directly. :)

[Koji Ishii]

I was once confused but IIUC:

• Ok to add content/browser if I need to run code in browser process.
  
• Code we used to add to content/renderer should be in WebKit/Source/modules.

Correct? Makes sense to me then.

/koji