Considerations for writing a third party binary that's included in Chromium?

[Charlie Andrews]

My team and I are working on reducing Chrome power consumption, and are considering writing a third party binary that will be called from Chromium to communicate with an external device (a power meter). 

We chose to write an external binary rather than include the communication code directly in Chrome because there are other clients that we plan to also communicate with the external device from (Telemetry and Android's systrace). Communicating with this device will require reading and writing from a serial connection and possibly communicating over sockets.

I have a few questions:

• Is there a precedent for shipping a third party binary with Chrome and calling into it?
• Ideally, I'd like to avoid writing my own serial communication and socket code on multiple operating systems, but am guessing that use of third party libraries in a binary that will ultimately be shipped with Chrome is discouraged, as it'll increase the Chrome download size. Is this right? Is there any clever way around this?

Any input is hugely appreciated!

--

Charlie Andrews |

Software Engineer |

char...@google.com

 

[Nico Weber]

On Thu, Oct 8, 2015 at 9:37 AM, 'Charlie Andrews' via Chromium-dev <chromi...@chromium.org> wrote:

My team and I are working on reducing Chrome power consumption, and are considering writing a third party binary that will be called from Chromium to communicate with an external device (a power meter). 

We chose to write an external binary rather than include the communication code directly in Chrome because there are other clients that we plan to also communicate with the external device from (Telemetry and Android's systrace).

Why does your code need to be in a separate binary for this? (As opposed to just library code that's linked in)

 

Communicating with this device will require reading and writing from a serial connection and possibly communicating over sockets.

I have a few questions:

• Is there a precedent for shipping a third party binary with Chrome and calling into it?

There's some precedent for shipping separate binaries (Flash; the PDF plugin used to be a separate binary; crashpad_handler on OS X is a separate binary), but doing this has a long list of drawbacks.

• Ideally, I'd like to avoid writing my own serial communication and socket code on multiple operating systems, but am guessing that use of third party libraries in a binary that will ultimately be shipped with Chrome is discouraged, as it'll increase the Chrome download size. Is this right? Is there any clever way around this?

Any input is hugely appreciated!

--

Charlie Andrews |

Software Engineer |

char...@google.com

 

--
--
Chromium Developers mailing list: chromi...@chromium.org
View archives, change email options, or unsubscribe:
http://groups.google.com/a/chromium.org/group/chromium-dev

[Charlie Andrews]

Why does your code need to be in a separate binary for this? (As opposed to just library code that's linked in)

The other binaries that are communicating with the BattOr are Python binaries. One option that we have is that we could write it as a third party library and link it into Chromium. Then, to make the code usable by the two Python binaries, we could write a small wrapper binary in C++ that just links the library and provides a small command line interface. Does this seem reasonable?

 

There's some precedent for shipping separate binaries (Flash; the PDF plugin used to be a separate binary; crashpad_handler on OS X is a separate binary), but doing this has a long list of drawbacks.

Do you know what those drawbacks are? One obvious one that I see is that our binary wouldn't be included in Chrome-wide tracking metrics, like how much memory Chrome's using.

[Nico Weber]

On Thu, Oct 8, 2015 at 10:15 AM, Charlie Andrews <char...@google.com> wrote:

Why does your code need to be in a separate binary for this? (As opposed to just library code that's linked in)

The other binaries that are communicating with the BattOr are Python binaries. One option that we have is that we could write it as a third party library and link it into Chromium. Then, to make the code usable by the two Python binaries, we could write a small wrapper binary in C++ that just links the library and provides a small command line interface. Does this seem reasonable?

Yes.

You could also keep your code somewhere in chromium's repo and have a git mirror of just that folder that other projects could use. That way, you don't need three-sided rolls for api changes. That's how e.g. rlz is set up.

There's some precedent for shipping separate binaries (Flash; the PDF plugin used to be a separate binary; crashpad_handler on OS X is a separate binary), but doing this has a long list of drawbacks.

Do you know what those drawbacks are? One obvious one that I see is that our binary wouldn't be included in Chrome-wide tracking metrics, like how much memory Chrome's using.

Some drawbacks of another binary from the top of my head:

* You need some cross-process communication mechanism (with your code linked into chrome, you can use chrome's IPC if your stuff wants to run in its own process for some reason)

* Binary size is larger

  - The linker can't dead-strip bits of the third-party library that chromium doesn't use

  - Statically linked libraries aren't included several times (e.g. libc++ on Android)

* You need error handling code if your binary is missing

* The binary needs to be mentioned in a bunch of .isolates so that it ships to bots correctly

* All platform installers need to be updated to learn about the new binary

[Primiano Tucci]

Don't want to derail the conversation but, worth checking this as it might make things easier: does the binary really need to be shipped or does it need to be always there only when running telemetry?

What are the use cases in which you'll need it?

IIRC such binary would be useful only if you have the actual BattOr hardware attached, right?  

[Charlie Andrews]

Nico, 

thanks, that makes things a lot clearer about why we might not want to add in a third party binary.

Dana,

thanks for the link. It's okay for this code to live wherever - it's not closed source. It looks like most of the concern in that thread you linked was around closed source code being included as a separate binary within Chrome.

Primiano, 

it's not just Telemetry - the code will also be run when someone has a BattOr connected, goes to about:tracing, checks the "systrace" checkbox, and clicks "Record".  But yep, you're definitely right - it's only useful if you have BattOr hardware attached.

[Charlie Andrews]

After thinking some more about this, I'm pretty sure that this library idea will work. If there are three files:

• battor_agent_lib.h
  (Header file for library to communicate with battor)
  
  
• battor_agent_lib.cc
  (Impl file for library to communicate with battor)
  
  
• battor_agent_bin.cc
  (Wrapper script that systrace and Telemetry can use to use the lib from Python)
  

then all three files can live in third_party (possibly being pulled in from the Catapult repo?), Chromium proper can just use the lib files, and Telemetry and systrace can use all of the files and still get the benefits of not having to duplicate writing the wrapper file. I think this is my new plan, unless anyone notices an obvious problem with it.