4 ms·

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 p

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?

sanjeevrad 13y ago
You would only link with the net library (and its dependent libraries - like base and crypto)
- icefox 13y ago
  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?
  - nilsbunger 13y ago
    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).
    - icefox 13y ago
      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.
    - bd_at_rivenhill 13y ago
      Why not just stick with a stable version for a while? Updating every month sounds like a huge headache.
      - erichocean 13y ago
        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.
nly 13y ago
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] [0] http://curl.haxx.se/ http://curl.haxx.se/ [1] https://github.com/joyent/http-parser https://github.com/joyent/http-parser [2] http://tatsuhiro-t.github.io/spdylay/ http://tatsuhiro-t.github.io/spdylay/ [3] https://polarssl.org/ https://polarssl.org/

sanjeevrad 13y ago

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

icefox 13y ago
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?
- nilsbunger 13y ago
  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).
  - icefox 13y ago
    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.
  - bd_at_rivenhill 13y ago
    Why not just stick with a stable version for a while? Updating every month sounds like a huge headache.
    - erichocean 13y ago
      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.

nly 13y ago

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] [0] http://curl.haxx.se/ http://curl.haxx.se/ [1] https://github.com/joyent/http-parser https://github.com/joyent/http-parser [2] http://tatsuhiro-t.github.io/spdylay/ http://tatsuhiro-t.github.io/spdylay/ [3] https://polarssl.org/ https://polarssl.org/