Bug 186410

Summary: Implement KeyedDecoderGeneric and KeyedEncoderGeneric
Product: WebKit Reporter: Don Olmstead <don.olmstead>
Component: PlatformAssignee: Fujii Hironori <Hironori.Fujii>
Status: RESOLVED FIXED    
Severity: Normal CC: achristensen, beidson, don.olmstead, Hironori.Fujii, ross.kirsling, webkit-bug-importer
Priority: P2 Keywords: InRadar
Version: WebKit Nightly Build   
Hardware: Unspecified   
OS: Unspecified   
See Also: https://bugs.webkit.org/show_bug.cgi?id=205902
Bug Depends on:    
Bug Blocks: 175336    
Attachments:
Description Flags
WIP patch
none
Patch
none
Patch don.olmstead: review+

Don Olmstead
Reported 2018-06-07 14:41:22 PDT
Currently there is a glib and CoreFoundation implementation of KeyedEncoder and KeyedDecoder. There should be a generic implementation of this available for platforms not using glib and CoreFoundation.
Attachments
WIP patch (18.20 KB, patch)
2019-04-17 01:15 PDT, Fujii Hironori
no flags
Patch (19.99 KB, patch)
2019-04-17 02:52 PDT, Fujii Hironori
no flags
Patch (20.00 KB, patch)
2019-04-17 02:53 PDT, Fujii Hironori
don.olmstead: review+
Fujii Hironori
Comment 1 2019-03-27 20:50:52 PDT
It seems that WebCore/platform/generic/KeyedDecoderGeneric.cpp can be implemented by using wtf/persistence/PersistentDecoder.h.
Fujii Hironori
Comment 2 2019-04-17 01:15:07 PDT
Created attachment 367619 [details] WIP patch
Fujii Hironori
Comment 3 2019-04-17 02:52:03 PDT
Fujii Hironori
Comment 4 2019-04-17 02:53:57 PDT
Alex Christensen
Comment 5 2019-04-17 09:29:39 PDT
Comment on attachment 367622 [details] Patch View in context: https://bugs.webkit.org/attachment.cgi?id=367622&action=review > Source/WebCore/platform/generic/KeyedEncoderGeneric.h:56 > + BeginObject, > + EndObject, > + BeginArray, > + BeginArrayElement, > + EndArrayElement, > + EndArray, We actually only need Object and Array here, but removing the others would require changing the CF version. Maybe we should just update both versions in the future. Then we could use recursion instead of having our own stacks, too. What do you think?
Fujii Hironori
Comment 6 2019-04-17 20:25:41 PDT
(In reply to Alex Christensen from comment #5) > We actually only need Object and Array here, but removing the others would > require changing the CF version. Maybe we should just update both versions > in the future. Then we could use recursion instead of having our own > stacks, too. What do you think? I agreed on your opinion. KeyedDecoder interface is badly designed. We can take two approaches in this case, SAX approach and DOM approach. In DOM approach, KeyedDecoder should have a iterator which indicates the current node. In SAX approach, KeyedDecoder should only have event driven callbacks. Anyway, we need to rewrite all clients in order to do the refactoring. * IDBKeyData::decode * deserializeIDBKeyPath in IDBSerialization.cpp * ResourceLoadStatistics::decode I guess those tasks are not so easy. Regarding having own stack, I'm not sure how we shoud do. Because I observes stack overflow in the 2500-level nested array in storage/indexeddb/key-type-array.html in WinCairo port.
Fujii Hironori
Comment 7 2019-04-18 21:28:01 PDT
Radar WebKit Bug Importer
Comment 8 2019-04-18 21:28:19 PDT
Note You need to log in before you can comment on or make changes to this bug.