Summary: | Implement Blob.text and Blob.arrayBuffer | ||||||||
---|---|---|---|---|---|---|---|---|---|
Product: | WebKit | Reporter: | Tetsuharu Ohzeki [UTC+9] <tetsuharu.ohzeki> | ||||||
Component: | DOM | Assignee: | Nobody <webkit-unassigned> | ||||||
Status: | RESOLVED DUPLICATE | ||||||||
Severity: | Normal | CC: | annulen, cdumez, esprehn+autocc, ews-watchlist, gyuyoung.kim, kondapallykalyan, ryuan.choi, sam, sergio, youennf | ||||||
Priority: | P2 | ||||||||
Version: | WebKit Nightly Build | ||||||||
Hardware: | Unspecified | ||||||||
OS: | Unspecified | ||||||||
Bug Depends on: | 213119, 213170, 213198 | ||||||||
Bug Blocks: | 196258 | ||||||||
Attachments: |
|
Description
Tetsuharu Ohzeki [UTC+9]
2020-06-13 10:45:59 PDT
Created attachment 401853 [details]
WIP
Created attachment 402103 [details]
Patch
Thanks for tackling this Tetsuharu! As far as I can tell, ENABLE_STREAMS_API is enabled by default (at least for macOS and iOS, I always have a bit of trouble remembering where to look for other ports). Given that, does it still make sense to use this implementation strategy? Or would it make more sense to try build these two methods on top of a general ReadableStream based implementation? (It may very well make sense to use this strategy, I am not professing support one way or another, simply asking). (In reply to Sam Weinig from comment #3) > Thanks for tackling this Tetsuharu! > > As far as I can tell, ENABLE_STREAMS_API is enabled by default (at least for > macOS and iOS, I always have a bit of trouble remembering where to look for > other ports). > > Given that, does it still make sense to use this implementation strategy? Or > would it make more sense to try build these two methods on top of a general > ReadableStream based implementation? (It may very well make sense to use > this strategy, I am not professing support one way or another, simply > asking). To be honest, I thought (planned) that we (probably I) should refactor these implementation after implementing `Blob.stream`. I'm not sure about that we can build these methods on the top of ReadableStream and its way is simple to implement them and I need to investigate about buiding on general ReadableStream to answer to your question. --------------- By the way, I seem all(?) ports has enabled ENABLE_STREAMS_API by default. Cannot we remove this flag? Should I post about it to webkit-dev? - http://trac.webkit.org/browser/trunk/Source/WTF/wtf/PlatformEnable.h#L465 - http://trac.webkit.org/browser/trunk/Source/cmake/OptionsFTW.cmake#L104 - http://trac.webkit.org/browser/trunk/Source/cmake/OptionsWin.cmake#L58 - http://trac.webkit.org/browser/trunk/Source/cmake/OptionsMac.cmake#L87 - http://trac.webkit.org/browser/trunk/Source/cmake/WebKitFeatures.cmake#L210 (In reply to Tetsuharu Ohzeki from comment #4) > (In reply to Sam Weinig from comment #3) > > Thanks for tackling this Tetsuharu! > > > > As far as I can tell, ENABLE_STREAMS_API is enabled by default (at least for > > macOS and iOS, I always have a bit of trouble remembering where to look for > > other ports). > > > > Given that, does it still make sense to use this implementation strategy? Or > > would it make more sense to try build these two methods on top of a general > > ReadableStream based implementation? (It may very well make sense to use > > this strategy, I am not professing support one way or another, simply > > asking). > > To be honest, I thought (planned) that we (probably I) should refactor these > implementation after implementing `Blob.stream`. I'm not sure about that we > can build these methods on the top of ReadableStream and its way is simple > to implement them and I need to investigate about buiding on general > ReadableStream to answer to your question. > > > --------------- > > > By the way, I seem all(?) ports has enabled ENABLE_STREAMS_API by default. > Cannot we remove this flag? Should I post about it to webkit-dev? Couldn't hurt to email webkit-dev. Comment on attachment 402103 [details] Patch View in context: https://bugs.webkit.org/attachment.cgi?id=402103&action=review > Source/WebCore/ChangeLog:14 > + without `ReadableStream` implementation. Since the goal is to go with supporting ReadableStream at some point, we should probably extract existing functionality from FetchBodyOwner/FetchBoydConsumer. Ideally, split FetchBodyOwner in two classes, one that will continue be the base class from FetchRequest and FetchResponse, plus be an ActiveDOMObject. And the other one which can be reused jointly with FetchBodyConsumer to implement text/arrayBuffer/ReadableStream. > Source/WebCore/fileapi/BlobPromiseLoader.cpp:65 > + delete this; This is a risky pattern. I do not think we need BlobPromiseLoader to be an ActiveDOMObject. It might be best to make Blob own the BlobPromiseLoader. (In reply to youenn fablet from comment #6) > This is a risky pattern. > I do not think we need BlobPromiseLoader to be an ActiveDOMObject. > It might be best to make Blob own the BlobPromiseLoader. text/arrayBuffer/ReadableStream is marked as `[NewObject]` in IDL. If we make Blob owns the BlobPromiseLoader, we need to hold multiple `DeferredPromise` or `BlobPromiseLoader` in Blob by vector or map, right? > text/arrayBuffer/ReadableStream is marked as `[NewObject]` in IDL. For text and arrayBuffer, this is the promise that is new, and this is already handled by the binding generator. Given the algorithm though, you are correct that text and arrayBuffer will be also brand new object. For ReadableStream, a new one needs to be created indeed. > If we make Blob owns the BlobPromiseLoader, we need to hold multiple > `DeferredPromise` or `BlobPromiseLoader` in Blob by vector or map, right? Right, this could be a HashSet. Thinking a bit more, BlobLoader in BlobLoader.h might be the one you actually want to use. It could be easily extended to support String, and could be probably extended to ReadableStream as well. *** This bug has been marked as a duplicate of bug 215663 *** |