search

w3c / oss-relations

Discussions and documents linked to the relationships W3C has or should have with the Open Source Software ecosystem
2 stars 2 forks source link

Landscape of W3C standards relying on single OSS implementations #2

Open dontcallmedom opened 3 years ago

dontcallmedom commented 3 years ago

To approach #1 in concrete terms, it would be useful to identify and document situations where W3C standards rely on a single OSS implementation, and understand better the terms of that dependency, the impact it has had on interop, spec implementation experience and possibly security concerns.

dontcallmedom commented 3 years ago

All implementations of the WebRTC API rely on libwebrtc which provides most of the building blocks necessary to implement the JavaScript API defined in the specification.

The library itself was built as an implementation of the IETF protocol stacks, and somewhat more indirectly, as a C++ representation of the W3C API. (in other words, the OSS work was driven by the standardization work)

Interestingly, that shared codebase didn't suffice (not even closely) to clear all interop issues - it took a lot of very significant efforts to get the various browsers to converge their WebRTC implementations over the past few years, and there are still significant efforts that are needed. Some of it is due to pure maintenance aspects (e.g. different versions of the libraries being used in different browsers), but some are a lot more structural: while libwebrtc deals with the on-wire plumbing, a lot of the WebRTC API is how it gets exposed in the browser event loop, how it manifests itself in intertwined state machines, what gets exposed in JS visible objects. I don't think anyone involved in the browser implementations would disagree that the role of the WebRTC WG discussions in getting interoperable browsers was absolutely essential and that the shared open source library was only a piece of the puzzle.

I don't have data on how multi-parties the code development was - the project is nominally supported by "Google, Mozilla and Opera", but I believe Google has been driving most of the work. The project governance opens up committing rights to anyone who gets 10-20 patches landed.

dontcallmedom commented 3 years ago

@svgeesus any chance you could document the situation for libwoff? maybe also other cases you're aware of (PNG?)

hober commented 3 years ago

ANGLE is perhaps another example. Offhand I think most if not all WebGL implementations rely on it.

dontcallmedom commented 3 years ago

thanks @hober for sharing this, I certainly wasn't aware of that shared dependency for WebGL.

I've started a list that documents these: https://github.com/w3c/oss-relations/blob/main/single-oss-implementations.md

xfq commented 3 years ago

It looks like most (if not all) browsers use ICU to implement css-text, ECMA-402, and some other specs.

Here's the "evidence":

The license of ICU: https://github.com/unicode-org/icu/blob/master/icu4c/LICENSE

svgeesus commented 3 years ago

@svgeesus any chance you could document the situation for libwoff? maybe also other cases you're aware of (PNG?)

WOFF 1.0 is prety simple and has multiple implementations. It references zlib, where most people use the zlib library by Jean-loup Gailly and Mark Adler .

For WOFF2, we need to distinguish between encoders and decoders. There are several encoder implementations, as listed on the WOFF2 implementation report.

WOFF 2.0 dates to after the time Microsoft became comfortable using OSS in Edge and before they switched from their own EdgeHTML engine to Blink. So, although we expected Microsoft to implement, they did not and just used the same Google library used in Chrome and Firefox. And now they use the Chromium engine.

iOS and MacOS X have a native WOFF2 decode capability, so Safari uses that.

Thus in practice most browsers other than Safari use one implementation, which is the Google WOFF2 reference code.

WOFF2 normatively references Brotli compression, where most people use the Google Brotli library. There was a proof of concept clean-room implementation of Brotli by Marc Adler, so this also has been implemented at least twice.

For PNG, there are multiple implementations. In practice, all browsers and most other implementations (such as image editing applications) use libpng which is currently maintained by Cosmin Truta.

libpng does not support the unofficial but widely used Animated PNG extension, so in practice a number of independent forks or patches are maintained to add APNG support to LibPNG. (This is not a very desirable situation; it's complicated).

PNG normatively references zlib, see above.

svgeesus commented 3 years ago

By the way JPEG (by which I mean JPEG compression used in a JFIF container as specified by the Independent JPEG Group, which is what most people call a "JPEG file") also has multiple implementations in theory of which one, libjpeg is overwhelmingly the one used in browsers. The History of libjpeg since 2010 is complicated and somewhat controversial and there are now multiple forks of it.