Repository navigation
Refine StructuredSerializeForStorage behavior #98
Description
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.
Activity
mkruisselbrink commentedon Apr 17, 2018
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
forStorageflag, where serializing for storage would explicit copy the data when needed, rather than just remaining a reference to a file on disk.annevk commentedon May 24, 2022
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 commentedon May 24, 2022
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 commentedon May 24, 2022
The problem is that a
Fileobject is clearly disk-backed and can reflect changes on disk. If thatFileobject was serialized before changes were made on disk, the deserializedFileobject should still reflect those changes.annevk commentedon May 24, 2022
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 commentedon May 24, 2022
nit: There is nothing magical about
Fileobjects being disk-backed, i.e. aBlobobject could be just as well disk backed, while aFileobject 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 commentedon May 24, 2022
I think
Fileobjects 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 withBlobobjects backed on disk, I'm not sure that's a case we need to cater for design-wise.