Libraries like STL (which Chromium code uses extensively) and boost are lower-level. Chromium has much higher level abstracts.

The reason to use specialized code is because your needs match them. Not everyone wants to bother linking to a general purpose library and adding a dependency when you can reuse some specific code and be done with it. Also, language standards cover libraries extensively and this is hardly a new trend and once it is standardized, it can no longer be considered third party. This has already happened quite a bit with C++11 which standardized many commonly used portions of the Boost library. Nevertheless, I mentioned the standardization aspect not to debate about it but to use it as an example to point out competing projects.

Yes, Chromium would be the technically correct usage, I used Chrome as it is the more familiar term.

I'm not sure what you mean by "optimized for use in browsers". I can't speak to the other 2, but Chromium is basically a vast collection of C++ cross-platform libraries that can be used in many applications.

While a class/library/etc might be used by chrome and all of its many users, it was originally designed to solve an issue for the browser and it might have a horrible api for anything else or much more likely be completely missing api that other applications would not only want, but need.

Actually if I'm not mistaken, the /base /net /threading (lower level components) etc. are common with the google server side codebase. At the very least, they share a common heritage. Whether they're kept in-sync on a regular basis... I couldn't say.

"optimized for use in browsers" means that collection of C++ cross-platform libraries can segfault a production server simply because it was not enough tested in other environments.

Will keep that in mind for my next post, thanks.

The core Chromium codebase itself uses the same license (a BSD-style license). Chromium itself uses certain other third-party libraries that have different licenses.

Qt is a higher-level application dev framework with UI support (like MFC but cross-platform). We were looking for lower-level constructs - especially in the networking and P2P areas.

I know that you are an ex-chrome dev so this is all moot as Chrome is the code you knew when you started, but really that is exactly what QtCore + QtNetwork is for. You don't have to use any of the GUI bits when you use Qt if you don't want to. I have written many "Qt" applications that were console apps simply to use the built in capabilities.

Edit: in fact just to highlight how similar it is, the way that QtWebKit works is that it is built on top of these modules in a [hand wavy] similar way that blink is built on top of the chrome development platform (I have hacked on Qt, WebKit, and Chrome).

> Qt is a higher-level application dev framework with UI support

Qt is a C++ application framework, it has both low- and high-level components, much like e.g. Cocoa.

> We were looking for lower-level constructs - especially in the networking and P2P areas.

Which Qt provides. Qt is modular and Qt has plenty of low- or intermediate-level modules, including extensive networking, storage and concurrency systems. Using Qt does not mandate using Qt's UI components.

Qt is reasonably separated into modules; I've deployed stuff that only depends on QtNetwork, QtSql and QtCore and all the other stuff doesn't get linked in (it's not even in the #include search paths).

(I haven't used Chromium libs and have no opinion about them)

Hell, Emacs meets those requirements. I'm half-serious too: org-mode and Gnus are nice pieces of software that don't have anything to do with text editing per se.

There are a lot of cross-platform base libraries out there, many of them (like Qt, GTK/GLib, and Mozilla's stack) well-documented and well-supported. These systems are meant to be reused; Chrome? Not so much. Besides the buzz factor, why would you want to base a product on Chrome instead of one of the codebases designed to be used that way?

You would only link with the net library (and its dependent libraries - like base and crypto)

And what about source and binary compatibility. What are the current guaranties? (his second question)

Edit: to be clear after you get your app up and running with the current version how much time has to be spent on ongoing maintenance down the road?

You build the libraries and link them into your libraries. If you maintain a cadence of updating your Chrome checkout every month, you will mostly be OK (though this can vary, of course).

So every month if I update I will be required to fix my application to work with the new versions of the library. Perhaps say 25% of my time will be _only_ on maintenance? And from what I recall things are not deprecated for a while, but very rapidly changed with little to no warning. This was a major headache.

Why not just stick with a stable version for a while? Updating every month sounds like a huge headache.

Because the Chrome team makes huge, breaking changes to their code APIs with breathtaking rapidity. If you don't update that often, it'll just get harder and harder and harder to do.

Google can do this (in general) because they have a single source tree (although IIRC Chromium isn't actually part of that). Point is: when you only care about your own code, as the Chrome devs do, third parties are in a really bad place to try and stay current.