Refine StructuredSerializeForStorage behavior

[inexorabletash]

Noted in w3c/IndexedDB#170 and w3c/IndexedDB#203 but better tackled here: HTMLs StructuredSerializedForStorage vs. Blobs/Files doesn't rigorously define that the data is cloned or referenced.

[mkruisselbrink]

Ah yes, good point. Part of this is the more general issue of defining Blob/File better with internal slots etc (#71), but then we do indeed probably want different serialization behavior depending on the forStorage flag, where serializing for storage would explicit copy the data when needed, rather than just remaining a reference to a file on disk.

[annevk]

It seems that with the current specification the problem is the reverse. We always clone data, but we shouldn't. Should we use this issue to track serialization and deserialization generally?

[mkruisselbrink]

The immutable nature of blobs should make it indistinguishable (apart from performance) if clones happen or not in most cases. But yes, we definitely need to fix this. I think this is one of the issues that #154 fixes, although I haven't looked at/worked on that PR in a long time...

[annevk]

The problem is that a File object is clearly disk-backed and can reflect changes on disk. If that File object was serialized before changes were made on disk, the deserialized File object should still reflect those changes.

[annevk]

I think for #154 it would help to have some kind of design document outlining what we are trying to achieve. I don't think we need to reflect all implementation details in the specification, but it should cover observable aspects such as this one.

[mkruisselbrink]

nit: There is nothing magical about File objects being disk-backed, i.e. a Blob object could be just as well disk backed, while a File object could just as well be memory backed (or IDB backed, or CacheStorage backed, or any combination of those).

But otherwise, yes, I think I agree. Ultimately while pretending blobs/files are just byte sequences makes the spec simple, this is just not the reality, and the serialization logic is just one aspect of that.

[annevk]

I think File objects are slightly different in that they get vended by <input type=file> (and potentially other places, such as copy & paste and drag & drop). While a technical user might be able to play around with Blob objects backed on disk, I'm not sure that's a case we need to cater for design-wise.