Standalone Chromium Libraries

[David Chen]

I have recently read an interesting article that speaks to the high quality and modularity of Chromium's libraries.

To my understanding, the base library, libbase, is available as a standalone package, and it looks like there are a number of other libraries, including courgette, crypto, dbus, gpu, media, and net, currently reside in separate repositories from Chromium src. Are there plans to separate some of the other libraries, such as ipc, jingle, remoting, etc.? 

The solid quality of Chromium's code is well-known, and it would be extremely helpful to be able to reuse Chromium's libraries in other C++ projects.

I noticed that there is a Chromium GitHub organization, but it appears to be mostly inactive. Given the number of developers use GitHub as a key place to look for libraries for projects, I think it would also be helpful to mirror some of these repositories on GitHub, similar to the way that Apache mirrors their projects.

It is understandable if this is might not be a high priority on the Chromium roadmap, but if possible, I would be interested in helping out with such an effort.

[Ryan Sleevi]

On Apr 17, 2014 1:13 AM, "David Chen" <da...@davidzchen.com> wrote:
>
> I have recently read an interesting article that speaks to the high quality and modularity of Chromium's libraries.
>
> To my understanding, the base library, libbase, is available as a standalone package, and it looks like there are a number of other libraries, including courgette, crypto, dbus, gpu, media, and net, currently reside in separate repositories from Chromium src.

You must be looking at an old Git mirror - all of the libraries you mentioned are integral parts of the Chromium source and kept in the same central (SVN) repository.

The article you linked to refers to a design taken by ChromiumOS that is not part of the overall goal or design of Chromium and has been a source of pain for the ChromiumOS team - but pain far less than the alternative of writing a separate platform abstraction layer. This isn't without issues - the ChromiumOS team is regularly impacted by refactors done within Chromium, such that they find they need to pin to (typically old) versions to have any semblance of code stability.

What I mean by this is that it is an explicit non-goal of Chromium to provide generic reusable libraries as you suggest. Such abstractions invariably get in the way of the momentum and flexibility required to build a secure, fast, reliable browser. That is, no one is trying to make an alternative to QT here - the goals and requirements of such a project almost invariably run counter to those of making a killer browser.

> Are there plans to separate some of the other libraries, such as ipc, jingle, remoting, etc.? 

Jingle is already separate - it is part of WebRTC, which is separately developed as an open-source project.

Equally, the IPC layer has been extracted by projects in the past (most notably, by Mozilla Firefox), even if that is not a goal of Chromium or the Chromium contributors.

At the same time, development of Mojo - a new framework for thinking of IPC and language bindings - is continuing to redefine how Chromium will look in the future. If you examine mojo (src/mojo), you can see it has minimal dependencies on base/, and thus could likely be ported to other systems. However, doing so - and maintaining such ports - is (generally speaking) not part of the goals of Chromium or the upstream maintenance. Mojo will and does serve Chromium's needs first.

>
> The solid quality of Chromium's code is well-known, and it would be extremely helpful to be able to reuse Chromium's libraries in other C++ projects.
>

Part of the reason for this quality is, unquestionably, a sense of purpose and direction for what the code needs to be and do. You can dig through these archives to see regular discussions about whether or not something belongs in "base" - with the answer far more often being "No" than "Yes". You also see aggressive refactorings, deprecation of old platforms/compiler toolchains/features (eg: non-Aura UI stacks on Windows/Linux), all of which are powered by an insatiable desire to make the best browser possible. Such philosophy doesn't work if the goal is changed to "Make high-quality reusable library components that anyone can consume".

> I noticed that there is a Chromium GitHub organization, but it appears to be mostly inactive. Given the number of developers use GitHub as a key place to look for libraries for projects, I think it would also be helpful to mirror some of these repositories on GitHub, similar to the way that Apache mirrors their projects.
>

Chromium already provides highly-scalable, canonical git mirrors. One of the main advantages of GitHub for such projects is the secondary features - like merging and pull requests - except those features are useless for Chromium's development model (gclient, Reitveld, repo, etc). While you could certainly mirror, I think the value here is far less than you suspect - especially in light of the non-goal comments above.

> It is understandable if this is might not be a high priority on the Chromium roadmap, but if possible, I would be interested in helping out with such an effort.
>

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

[Mattias Nissler]

On Thu, Apr 17, 2014 at 10:33 AM, Ryan Sleevi <rsl...@chromium.org> wrote:

On Apr 17, 2014 1:13 AM, "David Chen" <da...@davidzchen.com> wrote:
>
> I have recently read an interesting article that speaks to the high quality and modularity of Chromium's libraries.
>
> To my understanding, the base library, libbase, is available as a standalone package, and it looks like there are a number of other libraries, including courgette, crypto, dbus, gpu, media, and net, currently reside in separate repositories from Chromium src.

You must be looking at an old Git mirror - all of the libraries you mentioned are integral parts of the Chromium source and kept in the same central (SVN) repository.

He's probably looking at https://chromium.googlesource.com/ (which is up-to-date), and there are indeed "repositories" for the paths he lists. Those are just mirrors of subdirectories within the man chromium source tree though, so they are not separate repositories. 

[Claudio M. D. Souza Junior]

Well, I do use views, ipc, base and other to develop in C++. It is just the best C++ library currently available.

C++ community has last itself on the hands of all those academicians. That stuff being put forth by the international committee is so much more hard to be adapted. It is far worse than Chromium's source base.

When I began to use this code it was far less reusable than today.

Google could be, if they wanted, the main library developers inside C++ community. Everything in chromium (ninja, gyp, grit...) is just very practical for high productivity on C++.

[Stuart Morgan]

On Thu, Apr 17, 2014 at 8:01 AM, Claudio M. D. Souza Junior <claudi...@gmail.com> wrote:

Google could be, if they wanted, the main library developers inside C++ community.

Ryan and others in other threads have addressed this repeatedly. This is a non-goal of the Chromium project.

-Stuart

[Thiago Farina]

And just to state more clear what is the goal of the Chromium browser project. It is to "build a safer, faster, and more stable way for all users to experience the web.", which you can see when you navigate to http://www.chromium.org/.

A detailed description of these three principles are written here -> http://www.chromium.org/developers/core-principles

C++ is just a tool, a mean for an end, that allows the browser to be fast and lightweight, it would be safer if it was written in Ada for example. And one of the languages in use by this project, there are many more, like Objective-C, Java, Python, Perl, Assembly. Not sure if Go snaked in already though.

--

Thiago Farina

[Nico Weber]

(Somewhat off-topic, but we've successfully removed almost all Perl ( https://code.google.com/p/chromium/codesearch#search/&q=file:%5C.p%5Blm%5D$%20-file:third_party&sq=package:chromium&type=cs ). Go still isn't allowed ( https://code.google.com/p/chromium/codesearch#search/&q=file:%5C.go$&sq=package:chromium&type=cs – 3 files in a deps-pulled project).)

 

--

Thiago Farina

[Mike Frysinger]

I think the boost community is doing a decent job of filling that gap. their stuff is even influencing the standards bodies.
-mike

[ava...@gmail.com]

Very inspiring to read your answer. something to learn and take back for other projects.