It seems that WebCore/platform/generic/KeyedDecoderGeneric.cpp can be implemented by using wtf/persistence/PersistentDecoder.h.

Created attachment 367619 [details]
WIP patch

Created attachment 367621 [details]
Patch

Created attachment 367622 [details]
Patch

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?

(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.

Committed r244450: <https://trac.webkit.org/changeset/244450>

<rdar://problem/50039501>