He's talking about using bits and pieces of Chromium's infrastructure in other programs, but didn't address open source licensing at all. I haven't looked at it myself, but according to Wikipedia, Chromium's source is licensed under: "BSD license, MIT License, LGPL, MS-PL and MPL/GPL/LGPL tri-licensed code, plus unlicensed files". This is all fine, but anyone using this code needs to make sure they understand what license(s) the code they are using is under and what the terms of those licenses are. Just because it's open source doesn't mean you can just do whatever you want with it; even less restrictive licenses like BSDL might have conditions like the advertising clause, and you should always be aware of any copyrights in the code and be sure to preserve them.
That said, I'm sure the Chromium source is a great resource- just a strange and important omission from the article.
I would also suggest that anyone looking for a platform-independent runtime check out APR (Apache Portable Runtime): http://apr.apache.org. It's lower-level than some of the Chromium libraries mentioned in the article (it would be equivalent to the "base libraries" block in the "Chrome Development Platform" figure), but sometimes that's all you need. Plus, it's already designed as a library for other applications to use, there's no need to repurpose anything like you might have to do with the Chromium sources.
It's not too complicated. Everything with a different license is in src/third_party. Everything outside of that is under a BSD-style license. Need to watch your dependencies, but they aren't too hard to spot (and part of checking into third_party is a license check, so they're all well documented).
You can see them all if you go to about:credits in Chrome/Chromium.
I don't see how it would be different from using any other MIT-licensed code in your project. The Apache License doesn't seem any less restrictive than MIT at first glance?
Edit: I assumed the entire codebase was multi-licensed, it looks like you're saying that different parts have different licenses, which does sound like a headache.
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.
As someone not at Google, but who's re-used multiple parts of Chromium (as described in the article), the code (especially the stuff under base/) is possibly the best documented large-scale, open-source C++ codebase I've seen.
I haven't worked with Chromium, but the main C++ code-base at Google is like this for the most part too (especially the core stuff).
The C++ culture at Google is amazing, and proof that large-scale C++ can actually be really nice if you stay within best practices. It takes a lot of effort and experience from a lot of knowledgeable people to craft these practices, but thankfully Google publishes its C++ style guide (http://google-styleguide.googlecode.com/svn/trunk/cppguide.x...) so that everyone can reap the benefits of this.
Avoiding exceptions is a worst practice. The guide even admits they're only doing it because they're so far beyond a critical mass of exception-unsafe code that they've lost hope of solving the problem.
If the profession ever wants to produce anything reliable in C++, one of the first things that needs to happen is to start treating all unsafe legacy code like toxic waste, marking it clearly, handling it carefully in isolation, and disposing of it with prejudice as soon as possible. I don't ever expect to see this, which is partly why I switched to languages that try to handle failures and mistakes gracefully.
You say this very matter-of-factly. Many (myself included) do not believe in exceptions, and in C++ where they are poorly implemented, think not using them is best practice.
I would summarize, but this 10 year old article I've seen on HN a dozen times does a much better job than I:
Error handling is essential, but exceptions are far from a perfect solution. The Linux kernel is an impressively complicated, and robust piece of software and they get along just fine without exceptions. One just needs to be vigilant when handling errors.
I didn't really. IMHO as many in the comments stated, non-trivial "B" layer code makes the author's approach a mess.
Also I don't personally agree with the idea that exceptions communicate errors better. In his examples, he's taking an error code and converting it to an exception. Obviously all the information needed about that error is conveyed by the code, otherwise this approach wouldn't work.
Wrangling of this information shouldn't be happening in the middle of application logic. The return code should be acknowledged by the recipient so the necessary cleanup can be performed, then it should be piped to a central class in charge of printing/logging errors. Sprinkling these error code conversions all over the place makes things messy and hard to maintain.
The Linux kernel is an impressively complicated, and robust piece of software and they get along just fine without exceptions
Though I somewhat agree with you, in that C++ exceptions definitely are not the error handling method, such examples don't really mean nor prove much for this subject. Especially since the kernel isn't even written in C++ and is a pretty special beast compared to, say, a typical desktop or app. So now browse to https://en.wikipedia.org/wiki/List_of_fallacies and figure out which one you just used :P
I would never describe Linux as "robust". It seems everyone I know has seen it panic more than once, and shrugged it off not by fixing anything but by power-cycling the machine and hoping it doesn't happen too often. This means on top of a database of tens of thousands of bugs, there have been countless catastrophic failures which have never even been diagnosed. We only use it because everything else is at least that embarrassingly terrible and probably even worse.
Taking software seriously involves ensuring every failure is handled. Dropping them on the floor is almost never the right thing, which makes it crazy to have that quietly happen by default. Joel points out code without exceptions becomes very verbose and littered with local handling, but overlooks that it's so painful that most developers can't be relied on to actually do it.
I run quite a few linux boxes, and make them do lots of real work. Compared to other pieces of software, I find it quite reliable. This is especially true if you take into consideration the breadth of tasks and the performance requirements needed out of a monolithic kernel.
I'm in no way saying its perfect though.
> Taking software seriously involves ensuring every failure is handled
> it's so painful that most developers can't be relied on to actually do it
I agree with both of those points (as any decent developer would), but I don't believe exceptions remedy either of those issues.
The architects behind Go, truely some of the best minds in computer science, did not include exceptions because of this.
>If the profession ever wants to produce anything reliable in C++
This has already been done, so you are obviously wrong.
Exceptions are cute for small amounts of code. But as soon as you get a sizeable codebase, you have zillions of functions just waiting to explode your call stack in ways you could never expect.
Documentation doesn't fix it either. Even if you could somehow guarantee that every single function has detailed descriptions of its possible throws, you won't get devs to read all the documentation for every function in some piece of code that needs a small fix.
> Exceptions are cute for small amounts of code. But as soon as you get a sizeable codebase, you have zillions of functions just waiting to explode your call stack in ways you could never expect.
Exceptions do not "explode your call stack", and any function can fail in ways both documented and undocumented. Consistent use of exceptions that derive from a small and well-chosen set of base classes means that callers can choose where and how to respond to categories of errors, instead of being forced to litter all code with error handling conditionals. I have worked on large applications that made the transition to using exceptions, and when combined with strict RAII and other best practices, the effect is absolutely to make code easier to understand and much more robust.
The key is "small and well chosen set of base classes" for your exceptions. This is where you got the most benefit, and you probably know it. Without exceptions, you can have a class that represents well defined state such as either success or an error code, with the error code being well defined, returning an object of this class for all methods that need to return success/failure codes, and requiring that it be handled, so compilation fails if callers ignore the return value.
What's great about this is I might call a method that simply concatenates two strings, that is all it does, and I know this won't fail(OOM can always happen, but good luck recovering from that), so I don't return a status. I can call this method assuming no failure and no boiler plate is needed. With exceptions, there's always that possibility that an exception can be thrown. What if I call this method from code that needs to close resources? Great, now I absolutely must have RAII for cleanup, which is more complicated than just doing close(x). Also, what are you going to do when using 3rd party code with its own base exception class? Now, at the upper layers of your code, you have to have a handler for each base class. Without exceptions, someone might have their own status object they return, and I'll need to translate that, else my code won't compile. Your code will compile even though you might not handle that 3 party base exception class.
Of course, most times code just propagates the error up so that adds to boiler plate without exceptions.
I think the talk of using exceptions vs returning a status is a red herring. They have their positives and negatives, and we can argue this until the cows come home. The most important thing is to use a set of well defined success/error codes, whether this comes from exceptions or a returned status isn't really important. I've seen codebase with C++ exceptions working just fine, and I've seen c++ code with no exceptions, and it worked well. The commonality between these two cases is .... well defined error codes.
Exceptions are cute for small amounts of code. But as soon as you get a sizeable codebase, you start to understand the huge advantage they give: your code shrinks by an order of magnitude vs the same code with manual error propagation.
Avoiding exceptions isn't the worst practice. You still get automatic resource cleanup with RAII when you return from a function with an error code, which is a big win over completely unmanaged C.
I generally agree though, error paths are the last area I want to expose myself to flaky manual propagation and the 'well, I think I handled/freed everything' discipline. The regimental 'goto cleanup' type code you see in the kernel is not something I want in my projects.
I remember that last-gen game console SDK's explicitly recommended to avoid exceptions and disable them completely for performance reasons, and all C++ game-dev middleware I'm aware of don't use them or at least have support for disabling them. Don't know what the recommendation in the current console SDK's is. I never got into a situation where I thought "gosh, exceptions would be really nice to have in here".
> The C++ culture at Google is amazing, and proof that large-scale C++ can actually be really nice if you stay within best practices.
It's real-world C++, not 'Modern' or Boost- or 0x-C++ (not even C++98). There is a huge gap between C++ development in the trenches and what is published on the internet about C++.
If a simple C++ server is left in such a poor state, it stands to reason, how can there be a culture of C++ excellence? Why wasn't someone assigned to maintain the server? A culture is everybody, not just a few brilliant individuals or teams.
I'll just go ahead and call a spade a spade and say that this is a stupid line of conversation, and it's pretty clear that you know it.
Not only did the person you originally responded to even qualify with a "for the most part" -- thus allowing for the existence of bad code in said C++ culture -- every significant codebase in the verse has a neglected corner or three. Moreover, one man's "globally crappy" code is another man's halfway-decent code. We have no way of identifying how bad the code was, just that it was stalling a whole CPU without doing anything while I/O bound.
Finally, your whole point is ridiculous, because the slide deck you link is about finding a part of the codebase that has accumulated extreme cruft and replacing it with a new, clean implementation, which is exactly how you maintain a healthy codebase.
It was the server which allowed customers to download Google software onto their computers.
If your download server was slow and randomly disconnecting transfers for no good reason, resulting in potential customers giving up, wouldn't it be important?
You're blowing things way out of proportion because you don't have any idea what you're talking about.
It was a server involved in a fraction of Google's downloads comprising an even smaller fraction of Google's total egress. It took URLs of one form and redirected them to URLs of another form, where other C++ servers written by a staffed team (mine) actually redirected them to the actual C++ servers (again, deployed and maintained by my team) which deliver the downloads.
haberman wasn't talking about the state of Google's C++ codebase in 2005; he was talking about the state of Google's C++ codebase in 2014. This server was written years ago, using libraries that were years old at the time it was written. It wasn't maintained, and no team was responsible for it. The core libraries on which it was based were replaced by the libraries haberman lauded.
The only reason you can even try to use this server as an example is because you have no clue what you're talking about.
This is why I don't "get" go. If it was supposed to replace C++, why does it not compete with C++ directly? Why were they even using C++ for those projects in the first place?
Why use C++? Performance, universal familiarity, ability to access low level APIs (libraries, x86, syscalls), abundance of good tooling, manual memory management (+debug tooling), legacy.
Why not directly compete with C++? The performance and compatibility/"close to the metal" requirements are separate. Much of C++'s complexity comes from the latter. It makes sense to create a solution for applications that require one but not the other.
I think in the beginning they did think of it as a C++ replacement, but it has been a long time since anyone from the core team has used those terms (system language) to describe it. It is more of an alternative to Java or Python. Possibly the server described should have been written in Java in the first place.
As an example of this type of Chromium library re-use, Firefox and Firefox OS use the Chromium ipc library for messaging between the main UI process, plugin processes, and content processes (in Firefox OS or in Firefox with the experimental multi-process mode enabled).
Contrary to many, I'm profoundly concerned about the culture around Chrome development, and the attitude here is indicative of that. There really is a belief by those that work on it, or have worked on it, that it's much better than it really is, when what actually happened was it was much better than the competition at launch, but now there isn't much between them at all. This notion that Chrome is decent on mobile is still absolutely bizarre.
The more long term concern is the way it's creating a sort of development priesthood. You have the chosen few that are making decisions and developing the platform largely in secret and pushing the code out to mere mortals from on high. This wouldn't be so bad, except the decisions are not made in the interest of the mortals, but of the priesthood and the strategic interest of their Googly God, and they exhibit a level of contempt for the mortals by disallowing them direct access to things such as the components so lauded here. In an ideal world most of what's mentioned should not be in the C++ layer, but in JS, except the hooks to provide that are simply never going to be exposed (at least in the near term because of the JS performance it would be technically dubious), leading to this them and us situation where they get to develop all the low level stuff, and no one else does, especially if any patches would conflict with the interest of their lord and master. They simply aren't dogfooding their entire development stack. Mozilla, for all their flaws, do actually engage the rest of the world in what they're doing, and early Java, while slow, did have a relatively small JVM with an enormous class library which was mostly written in Java itself. You could argue Sun's error was to Swing too far in the other direction by insisting on being all Java where at the time it really should not have been.
So yes, sadly I've come to view many Chrome devs as smug self serving slightly delusional types persistently confused that the masses don't acknowledge their brilliance, and this piece is evangelism to try and persuade us of this. The truly scary part of this is they just might be right to have this point of view in order to prevent what happened to Android where groups outside succeeded in nullifying many of the expected advantages of a standard open mobile platform, and I suspect it's this which has led to their open but closed approach to things.
>In an ideal world most of what's mentioned should not be in the C++ layer, but in JS, except the hooks to provide that are simply never going to be exposed
Do you even know what you are talking about? the only thing that is reasonable to be written in javascript is webkit, specially the DOM.. and as far as i know, the chromium folks are already doing it.. (its called oilpan, i think)
There's no way the other parts could be working in javascript.. javascript is not that sort of language.. first you need a non-GC language: C, C++, Rust or ObjC (if you can stand it)
Than you need access to the native threads, and process, net, etc.. of each platform and provide native bindings for each platform.. and you need to do it fast(this probably means AOT compilation).. and again javascript is not that sort of language..
People need to stop being lazy and learn to use different tools for different needs..
I wont even comment on the cultist non-sense part.. but the source of chromium is there.. you can use it.. its open.. what could be bad about it?
Im using the chromium codebase to build a sort of netxgen "browser" (not web browser).. but more akin to a application platform with p2p in mind (and other crazy ideas). While the idea proposed by the author may sounds cool, i think chromium is a huge codebase to be used like the author says so trivially..
Its ok; if you need multiprocess ipc + net + actor-based thread concurrency + gpu compositor + webkit.. (like i do)
But, dont know if it worth the trouble otherwise..
For instance, it takes a very long time to compile everything, it takes long to debug (the final chrome binary with debug symbols end with 2G.. all loaded in the heap) and you got a big codebase to know about.. so use it with care and in need.. otherwise you will waste your precious time trying to kill a fly with a canon
This is the argument that resonates with me the most. Unless you're already intimately familiar with the codebase and build system (with all their attendant quirks), it could consume a huge amount of time and effort to tease apart the stuff you need from the vast chromium codebase.
For the record, I'm working on a new C++ project where I ended up picking up small (very small) pieces of chromium codebase with the rest being in conservatively written C++ (but not as conservative as described in google code-style guide). In general, I'd say /base and /threading libraries are useful sources to raid at the beginning of your project. These are high quality implementations of basic things most programs would need and somewhat easier to disentangle from the rest of the code.
i think theres a safe threshold someone can use as a rule, before things get too much complicated..
first: know how to use gyp and ninja build tools
then.. you can embed: base, crypto, net and ipc..
Anything more than that, things start to get more complicated.. for instance: if you want to use the 'ui'.. then you have to embed 'cc' and 'gpu'.. and to work right.. you will need the browser process + the gpu process.. and will have to create a custom-renderer, or adapt the renderer process to yourself.. so now you will realize you are doomed!
The other Chrome components past the ones i've pointed out, will need to use the IPC and multiprocess logic from chrome.. so that part should only be used in very specific scenarios..
Edit: i think the 'cc' module, the chrome compositor, also has some sort of autonomy from the multiprocess IPC core.. so could also be used with: base, crypto, net and ipc
Can i contact you in the email you are giving in your profile?
I dont think exposing it directly here wont be very succint.. (i wish this was more simple to explain about)
since there are some details about how the technology works (or should work)
and since i dont wrote any docs about it besides my personal notes.. i was expecting
to jump here at HN with a working prototype for us to play with in some months from now..
as it would be easier for people to wrap their heads around it
Im glad to talk about it to anyone interested, and if anybody else is curious, just drop me some mail
at fabiokaminski at gmail dot com
With more people interested and involved, of course i can just stop coding and write a doc or paper about it in more
detail.. i know theres a lot of pressure out there for something like this.. as the journey for me to get into this formula
was driven by my own needs, and the lack of something already real that i could use... (couldnt do it for web browsers
and app platforms wasnt really there)
It wasnt easy to get into this formula.. and i can say that this engine is REALLY cool, once its a reality
i have no doubts, it will be a much more heavy-weight sucessor of what the browser could have been if
it was reimaginated and designed to be more powerful than it is.. (and with the things we do know now :))
I'm posting this from a Chromebook Pixel, which I use for all of my development. No crouton, just stock ChromeOS.
This movement is really interesting to me. If I could clone myself, I'd be working on an exokernel in Rust that just exposes a V8 VM, and uses a DOM implementation as the native drawing interface. Processes == tabs...
Of course, there's higher level work that needs to be done to expose more of the machine in JavaScript. Check out http://extensiblewebmanifesto.org/ , signed by Google, Mozilla, and W3C TAG members, as well as #extendthewebforward on Twitter.
I use it primarily for PGP. I've been thinking about trying out Linux from Scratch with it, but haven't had the time.
I made a decision to start using the Chromebook to dogfood this particular vision of computers: I'm not happy that it involves Google, but they're the only one with an implementation that's this far along, unfortunately.
I've been meaning to write on this whole thing, haven't had the time...
Can you give us some insight into how you develop on ChromeOS? What editor do you use? How do you run things like GIT? What surprised you that was so easy? What did you find more difficult that you wish was easier?
I'm the kind of guy who lives in the terminal. The only GUI program I use is a web browser.
I've been trying out Nitrous.io, and it's pretty great. I also SSH into a Digital Ocean droplet too. I just use Vim and git and everything else as normal.
> What surprised you that was so easy?
Mostly that it works.
> What did you find more difficult that you wish was easier?
I still haven't done any international travel with it yet, I bet I'll spend a lot more time using my X1 Carbon then.
I've tried out a little development on a Nitrous box using Vim myself. It seems like it would be possible to be pretty productive in it, if you were really good with Vim and all of the command-line tools. I managed to get some things done, but working with Vim just seemed to put so much friction into things. I try to keep working with Vim enough to get more comfortable/productive in just that, but it seems like a pretty long road.
I tried it out on a VM chromeOS when I was thinking about getting a Chromebook Pixel, but I ended up going with a Macbook instead - seems like more features for the same amount of money.
A lot of VNC Viewer for Chrome is just the standard RealVNC stuff compiled into NaCl, so you should find the performance to be pretty good. If you've used any of RealVNC's mobile apps you should have a good expectation of what you're getting (except better because you might be using a wired connection & a desktop computer has more power than a mobile device).
Yes, it absolutely does, and I am very much not happy about it. I am the most anti-Google person I know.
Unfortunately, it is impossible to live in a world of ideals, and so, I must compromise from time to time. As I mentioned elsewhere, I have another machine with 100% free software that I use for PGP when I need to keep secrets.
Linux? FreeBSD? Haiku? There's plenty of choices, and all of them have modern web browsers available (and frankly, better browsers than Chrome. People should really stop drinking google kool aid and take a look at the chrome codebase first before using it).
XULRunner is a good option to build HTML or XUL based apps. We were looking for a great cross platform library for native (c++) apps. With support for OS specific features.
The UI component of it is ugly as hell, and the API style is a little antiquated. It also isn't as comprehensive as Qt, and there isn't as many resources out there for it.
I worked for a high end audio company and used it in one of their acoustic simulation softwares.
One of my main jobs was porting this project to Qt.
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?
These are at very different levels. For example, XULRunner itself is partly built on top of (a small portion of) Chromium library code, as noted elsewhere in this discussion.
Correct. Chrome is breaking no new group here. XULRunner aside, you can also use Mozilla's NSPR library for cross-platform basic services and NSS for TLS.
Huh. When i read that article, i immediately thought of NSPR - as in, this is the Chrome alternative to NSPR. But it's built on top of NSPR? I suppose Chrome-as-a-platform provides more abstraction and richer services than NSPR.
Just a heads up, Web of Trust has this sited rated very poorly[1], ostensibly for spam. As a result, any users with the Web of Trust browser extension installed are shown a Big Scary Warning that they must click through before seeing the site's content.
The warning is based on one review, and doesn't seem accurate in this case, so this might be something to try to get resolved.
Chromium is _huge_. If I just wanted to use the HTTP library (with tls and spdy) then how would I build just that, and cleanly integrate the build into my own project in a way that won't require constant revisiting every time I update my chromium sources?
I wouldn't go there. If I needed high level HTTP access I'd go with libcurl [0]. If I wanted a HTTP parser I'd consider Joyents http-parser library from nodejs (no dependencies at all) [1]. If I wanted a SPDY library, I'd consider spdylay (used by aria2 I think) [2].
All of these libraries are MIT licensed, well documented, and designed to be very focused libraries with very little feature-creep.
For TLS: PolarSSL has worked for me, but its GPL and tends to break ABI quite a bit [3]
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.
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.
"Web apps are a good solution some of the time (except for that little detail called IE!)."
This statement makes very little sense. You say that you can't use web apps because you would require client have a specific app (chrome) on their machine, but then you say the solution is that they must have a different specific app on their machine. I would re-write that or remove it.
While interesting, I think the headline is a bit hyperbolic.
The Chromium project doesn't build on many platforms, and the build system they use for it is minimally documented.
While individual bits of code might be reusable on other platforms, I'd be hesitant to base any project I create on Google's codebase given the lack of portability and their reliance on arcane buildsystems.
I've also used Chromium libraries for cross-platform development in the manner you have suggested. What you might want to address is how you handle deficiencies in the base libraries --- how much do you have to rewrite when you see that the base implementations, which are fine for Chromium, don't offer the features that you need in your app? An example: it includes a fs-events system, to monitor for changes in files, but it is crippled to work around a bug in one version of Mac OS X, and so in the end, one probably has to write their own file-monitoring logic for each platform (or copy the Chromium code, and then modify it). Additionally, once you start modifying the base libraries to add the features that you require, how do you merge with the changes that the Chromium team inexorably publishes?
Hi, maybe it's a stupid question, but could you write a C application that makes use of these libraries? I mean, when you talk about integrating with the Chromium source code you mean cherry-picking some code and dropping it into your C++ code or you're talking about linking it at compile time?
Do you have a link to the documentation? And if there is no documentation for this many year old project why is that? Is using it in this manor different than the explicit goals of that code (which from what I understand is to only support chrome)
Chromium, Gecko and Webkit codebases are huge, they are hard to compile. They are optimised for use in the browsers and nothing else. They are not universal runtimes yet! I like that idea but please don't make it sound like chromium runtime is ready for everybody to use for their projects.
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.
Recommending Chrome is a bit like recommending bionic when everyone else is enjoying (e)glibc?
The Chrome runtime has some good libraries but using that over say Qt really only makes sense if you're a (former) Chrome developer. For everyone else it's just needless pain.
agreed. It sounds good but I can't imagine using it over some other x-platform lib which probably has fewer headaches. It's just way too big for what the author of the original post had in mind.
Sounds like Chromium might be the successor to APR, the Apache Portable Runtime. I believe that the authors of Chrome consciously tried to provide functionality that replaced APR, presumably because of their multiprocess model.
This is what mod_pagespeed/ngx_pagespeed does. We need many basic things and we use the Chromium libraries for that.
(You could say that's because we're kind of like a browser, but we don't actually use the most browser-like components of Chromium. We do need an http(s) fetcher and html/css/js parsers but the Chromium ones aren't a good fit for our usage.)
Chrome is more like Java or .NET runtime than C runtime. You can build full blown apps as Chrome packaged apps. Google has not polished it very well. If done well, developers can use it to build apps that run on Windows/Mac/Linux without change.
It CAN be like Java or .NET if you build on top of it with packaged apps, or it can be like the new C runtime if you statically compile bits of chrome in to your application, as a 'stack' that you build on, which is what the author is describing.
While looking for cross-platform (iOS and Android) networking and security resources, Google kept giving me references to the Chrome codebase. Having compiled Chromium for a homebrew Chrome book (and tired of copying settings between two separate codebases), I'm going to try this. :)
A big shout out to the author of this stack overflow post, where I first confirmed that it might indeed make sense to develop function-based middleware in C or C++ and share it between iOS and Android to bridge the low and high levels of your app: http://stackoverflow.com/revisions/5234868/2
This is interesting. Ideally, if the rendering and audio parts are of high performance enough, it could be used as platform abstraction for game development.
Have you seen original real player it's pretty amazing tech too. Except that it's forever ago. Just epic citadel vs when they actually coded that demo.
Interesting, it seems kind of like the scenario where the "web stack is the new GUI", with desktop projects like Light Table being built on Node-Webkit. You're reusing browser infrastructure for native apps.
What other alternatives are there? Apache Portable Runtime?
But otherwise I still see no reason to use something designed for a specific use-case over something which is designed for general development. Though if it is a proprietary app it might work because there people seldom care about using latest version of libraries, sad as it may be.
Further, I really don't like the idea of adding a third-party draw API to a language standard. Dunno if we really want to blur the line between language and library.
There is a lot of code in Chromium that covers ground that Qt does not and there are good reason to prefer permissive licensed code for your project that you can directly modify. Qt is a fine library but hardly the be all end all of what is out there. ISO C++ committee recently posted to the Cairo library and C++14 might have a standard 2D based on it. There is a lot of room for different projects
Just started experiencing this early on this week via Node Webkit, it is just awesome what NW with Chromium brings to the table.
The first thing that came to my mind is that this should have been there 15 years earlier through Java/Embedded browser. However the powers of the time (read IE) were not interested/even actively blocked embedded browser usage.
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.
That's how NSPR was/is used by projects other than Netscape/Mozilla, too. Producing such a library is generally an unavoidable consequence of writing a popular multi-platform application -- unless you reuse someone else's.
I think Qt is a much lighter and feature rich alternative. Light because you only need and see the Qt dlls and feature rich because the things described are already in Qt.
That said, I'm sure the Chromium source is a great resource- just a strange and important omission from the article.
I would also suggest that anyone looking for a platform-independent runtime check out APR (Apache Portable Runtime): http://apr.apache.org. It's lower-level than some of the Chromium libraries mentioned in the article (it would be equivalent to the "base libraries" block in the "Chrome Development Platform" figure), but sometimes that's all you need. Plus, it's already designed as a library for other applications to use, there's no need to repurpose anything like you might have to do with the Chromium sources.