Stories
Slash Boxes
Comments

SoylentNews is people

posted by Fnord666 on Sunday June 23 2019, @04:11PM   Printer-friendly
from the curling-in-software dept.

Submitted via IRC for Bytram

Google to reimplement curl in libcrurl

Not the entire thing, just “a subset”. It’s not stated very clearly exactly what that subset is but the easy interface is mentioned in the Chrome bug about this project.

The Chromium bug states that they will create a library of their own (named libcrurl) that will offer (parts of) the libcurl API and be implemented using Cronet.

Cronet is the networking stack of Chromium put into a library for use on mobile. The same networking stack that is used in the Chrome browser.

There’s also a mentioned possibility that “if this works”, they might also create “crurl” tool which is then their own version of the curl tool but using their own library. In itself is a pretty strong indication that their API will not be fully compatible, as if it was they could just use the existing curl tool…

“Implementing libcurl using Cronet would allow developers to take advantage of the utility of the Chrome Network Stack, without having to learn a new interface and its corresponding workflow. This would ideally increase ease of accessibility of Cronet, and overall improve adoption of Cronet by first-party or third-party applications.”

Logically, I suppose they then also hope that 3rd party applications can switch to this library (without having to change to another API or adapt much) and gain something and that new applications can use this library without having to learn a new API. Stick to the old established libcurl API.


Original Submission

 
This discussion has been archived. No new comments can be posted.
Display Options Threshold/Breakthrough Mark All as Read Mark All as Unread
The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
  • (Score: 3, Informative) by takyon on Sunday June 23 2019, @05:41PM (3 children)

    by takyon (881) <takyonNO@SPAMsoylentnews.org> on Sunday June 23 2019, @05:41PM (#859108) Journal

    "Big pile of Not Happening."

    - Google and Mozilla

    --
    [SIG] 10/28/2017: Soylent Upgrade v14 [soylentnews.org]
    Starting Score:    1  point
    Moderation   +1  
       Informative=1, Total=1
    Extra 'Informative' Modifier   0  
    Karma-Bonus Modifier   +1  

    Total Score:   3  
  • (Score: 0) by Anonymous Coward on Sunday June 23 2019, @08:37PM

    by Anonymous Coward on Sunday June 23 2019, @08:37PM (#859140)

    Mozilla too. I hack on both browsers professionally, and in both cases the projects appear to consist of a core group of fewer than 100, who likewise hack around. Putative performance gains are chased, additional tracking implanted according to their bosses' demands, all without any regard to code clarity, stability or any software engineering guidelines. In fact, it appears one of their private goals is to prevent any outsider from being productive with the source.

    Say you want to keep stats on how many DOM nodes are created. In more rigidly developed software, you may find the constructor for a DOM node, or its factory, and maintain count through there.

    Browser X has something like that, but then you find out that sometimes nodes are constructed incomplete, filled in later or discarded. Fine, you do stuff to handle those cases. Two years later when you retarget your work to the newest version, everything has changed. For example, classes helpful to your work have been removed or hidden, they add a complex destruction process where nodes are put in limbo, then restored from there if a node with the same parameters happens to need construction again. Supposedly because it happens a lot and saves a few milliseconds. You need to pretty much rewrite everything.

    The Linux kernel also has performance needs, but AFAICT they will not needlessly complicate things to save a minor amount of time (SystemD is not Linux). Kernel developers regard performance redesign to come with a significant amount of commitment to that design over the following years. Browser design needs a messias like Linus. :)

  • (Score: 3, Interesting) by darkfeline on Sunday June 23 2019, @11:47PM (1 child)

    by darkfeline (1030) on Sunday June 23 2019, @11:47PM (#859189) Homepage

    Uh, isn't this exactly what is happening? They're taking the networking stack which was bundled in a monolithic application, and exposing it as a standalone library and potentially a separate utility.

    Personally, I don't see the point; I'm all for having one standard (one libcurl, yes, but also, one Linux, one systemd, one browser engine, etc). However, I'd wager that a lot of SoylentNews readers who will poo-poo this ("why make a new library when libcurl already exists") are also hypocritically demanding more web browser diversity.

    --
    Join the SDF Public Access UNIX System today!
    • (Score: 2) by takyon on Monday June 24 2019, @01:13AM

      by takyon (881) <takyonNO@SPAMsoylentnews.org> on Monday June 24 2019, @01:13AM (#859201) Journal

      we need to decouple storage backend, history, bookmarks, filtering, sandboxing, rendering, anything which is hidden inside, to separate tools.

      Is this happening with Google Chrome?

      --
      [SIG] 10/28/2017: Soylent Upgrade v14 [soylentnews.org]