Open inexorabletash opened 6 years ago
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.
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?
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...
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.
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.
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.
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.
Noted in https://github.com/w3c/IndexedDB/issues/170 and https://github.com/w3c/IndexedDB/issues/203 but better tackled here: HTMLs StructuredSerializedForStorage vs. Blobs/Files doesn't rigorously define that the data is cloned or referenced.