Streams API (Web Engines Hackfest 2015)
0 likes664 views
The document discusses streams API, which enables asynchronous I/O processing by reading and writing data chunks. It can pipe data between streams and supports automatic transformations. The spec defines ReadableStream, WritableStream, and TransformStream interfaces. It is useful for tasks like loading video segments or sending messages over websockets. The implementation in browsers uses JavaScript builtins tied to WebIDL to define the API in a maintainable and performant way while avoiding memory issues, though it requires care around security.
Streams API (Web Engines Hackfest 2015)
- 2. What is it? • Enabling I/O processing • Read chunks asynchronously • Write chunks asynchronously • Pipe from a stream to another • Automatic transformations • Any kind of chunk • Strings • ArrayBuffers • Potatoes • Any JSValue cocktail
- 3. What is it good for? • Get me this video segment ASAP • Without streams API: download it, then read it • With the streams API + MSE: start downloading it and pipe it to MSE • Using SourceBuffer.appendStream • Get me this WebSocket-like connection on HTTP • ReadableStream/WritableStream to receive/send messages • With HTTP/2, just one TCP/IP connection for both WebSocket- like channels and regular HTTP content • Any I/O use-case actually… • Wrapping of all data sources in a single clean model • HTTP, WebRTC, file system
- 4. What is in the spec? • Stable • ReadableStream • Except pipe operations (related to WritableStream) • Beta • WritableStream • Experimental • TransformStream • ReadableByteArrayStream • May be almost merged with ReadableStream
- 5. What it is good for/bad for, internals? • Promise based • Async is good but • Still a bit expensive • Use it for arrays, objects • Probably not to pass one byte after one byte
- 6. Where will it be? • Fetch API • Retrieve data progressively • Send data progressively • MSE API • Append stream • WebRTC • Plan to use it
- 7. ReadableStream API remarks • ReadableStream : locked, cancel, getReader, pipeThrough, pipeTo, tee. • Underlying source : start, pull, cancel. • Strategy : highWaterMark, size • Controller: enqueue, close, error, desiredSize • Reader : closed, cancel, read and releaseLock
- 8. How is it working? httpResponseBody.pipeThrough(decom pressorTransform ) .pipeThrough(ignoreNonIm ageFilesTransform ) .pipeTo(m ediaG allery);
- 9. Where is it? • Chrome • Shipped • ReadableStream tied to the Fetch API response • Ongoing • ReadableStream created by scripts • ReadableStream for progressive uploads using fetch • Mozilla • Will start 25/12/2015 (roughly) • IE • Support of an earlier version of stream/XHR as producer • WebKit • ReadableStream fully implemented • pipeTo to be broken by the spec • WritableStream fully implemented
- 11. First Approach – Initial steps • C++ implementation • Regular WebIDL to bind API with JavaScriptCore • Needed improved promise binding code • Initial prototype supporting byte arrays • Nicely working • Not too complex
- 12. First Approach – second steps • Support of any JavaScript value • WebIDL • Starting to add special cases in the binding generator • Adding a lot of JS code in WebCore/bindings/js • Storing JS values, making them not collectable • Calling JS functions • Handling of asynchronous behavior, JS promises • Overall conclusion • Code difficult to relate with the specification • Difficult to keep proper reference counting • Templates to add further specialization for byte array
- 13. Second Approach – JS Builtins • JS Builtin is a JavaScriptCore feature • Introduced a few years ago • Promise code is mostly JS builtin • Enable JS Builtin into WebCore • Integrate it with WebIDL binding generator • Streams API implementation • WebIDL code • JavaScript code • Some limited C++ code • 80 lines • Except for automatically generated code
- 14. JS Builtins tied to WebIDL • WebIDL • JavaScript built-in
- 15. JS Builtins calling C++ methods • Private keyword
- 16. JS Builtins misc • Conditional compilation • @conditional • Constructor as JS built-in • @assert • JS built-in functions (helper routines) attached to the global object • @internal
- 17. JS Builtins build • Update CMakeLists.txt • Add IDL file in WebCore_NON_SVG_IDL_FILES • Add JS file(s) in WebCore_BUILTINS_SOURCES • 1 file for WebIDL tied routines (stored in the prototype) • 0/1/+ files for helper routines (stored in the global object) • Update Source/WebCore/bindings/js/WebCoreBuiltins.h and Source/WebCore/bindings/js/WebCoreBuiltins.cpp • When adding a new JS built-in file • To be automated soon hopefully
- 18. Overall experience • Easier to write JS code then to write C++ binding code • No more crashes, no more memory leaks, no more ref- counting cycles • Performances is not really an issue • Apple made measurements on the Promise implementation and saw some improvements • Everything is nice, except… • No JS built-in code debugger • Back to console.log(“potato 1”); • JS builtin security issues
- 19. Security issues • JS builtins run in the same world with the same GlobalObject as user scripts • Modifying a prototype or a user object may affect JS built-in code • First possibility: JS built-in code may break • What if mediaDevices is overridden by user scripts? • What if mediaDevices prototype is changed.
- 20. Security issues – leaking information
- 21. Security issues – current rules • Do not use functions under the control of the user operations.push(…) operations.@push(...) • Do not use prototype of objects under the control of the user function processValue(promise) { promise.then(…) } function processValue(promise) { promise.@then(…) // ok but it may break } function processValue(promise) { @Promise.prototype. @then.@call(…) // ok but so unreadable } • Beware of Promise • Might want to use InternalPromise if you are doing chaining
- 22. Security issues – we need something better • So easy to fall into that trap • Not so easy to find the holes • How can we improve the situation? • Testing tool to catch these errors • JS builtin check style? • JS proxy object in Debug mode to control how are accessed objects • Sanitizers • Should we change the infrastructure? • Run the built-ins in a more secure environment • Chrome is doing that in a completely separate world • Cannot pass promises, JS objects.... Between the worlds • Input most welcome
- 23. Tentative conclusion • Streams API is • Very maintainable • Fast enough (more study needed) • But • Potential security issues • We fixed the ones we know of • Need to improve JS built-in tooling • Think about JS built-ins when adding WebCore/JSC specific code • Like in WebCore/bindings/js