Where do you test that property? Adam
On Tue, Sep 18, 2012 at 12:43 PM, Oliver Hunt <oli...@apple.com> wrote: > JSC's SerializedScriptValue has always been versioned (having learned the > horror of no versioning with localStorage :( ) > > Newer formats (obviously) can't be read by older clients, but the > serialisation is intentionally forwards compatible. > > --Oliver > > On Sep 18, 2012, at 12:36 PM, Adam Barth <aba...@webkit.org> wrote: > >> This is an interesting case because it's important for the >> serialization format to be consistent across time (so that an >> IndexedDB created at one point in time can work at another point in >> time), but it's not important to be consistent across embedders >> (because IndexedDB created by Safari don't need to be readable by >> Chrome and vice versa). >> >> Perhaps we shouldn't use LayoutTests to test this functionality. >> Instead, it might make more sense to use API-level tests that check >> that a particular embedder API is stable and working as expected. >> >> Adam >> >> >> On Tue, Sep 18, 2012 at 12:19 PM, Alec Flett <alecfl...@chromium.org> wrote: >>> Background: some of the storage systems use SerializedScriptValue to persist >>> structured-clonable objects >>> (http://www.w3.org/TR/html5/common-dom-interfaces.html#safe-passing-of-structured-data) >>> - most of this is implemented in a V8 or JSC-specific implementation of >>> SerializedScriptValue. >>> >>> I'm adding tests for the actual values stored with SerializedScriptValue so >>> that we can move forward with serialization changes without breaking >>> backwards compatibility. >>> >>> So many of my js tests boil down to: >>> >>> testSerialization({}, [0x01ff, 0x003f, 0x7b6f, 0x0000]); >>> >>> Which makes sure that these two representations are equivalent by going in >>> both directions. >>> >>> The issue I'm hitting is that JSC has a different implementation with a >>> different storage format, and the serialization/deserialization between the >>> two storage formats is not compatible - the above code works great on V8 but >>> JSC uses different bytes. >>> >>> I can't address this with just expectations files (i.e. only check that {} >>> serializes to some byte array, and have different expectations depending on >>> the port) because I need to check that specific inputs (such as old V8-based >>> formats) can also deserialize back into the right native objects. >>> >>> What I kind of want is something like: >>> >>> #ifdef JSC >>> <script src="serialized_script_tests_jsc.js"> </script> >>> #endif >>> >>> #ifdef V8 >>> <script src="serialized_script_tests_v8.js"> </script> >>> #endif >>> >>> Thoughts? >>> >>> _______________________________________________ >>> webkit-dev mailing list >>> webkit-dev@lists.webkit.org >>> http://lists.webkit.org/mailman/listinfo/webkit-dev >>> >> _______________________________________________ >> webkit-dev mailing list >> webkit-dev@lists.webkit.org >> http://lists.webkit.org/mailman/listinfo/webkit-dev > _______________________________________________ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev
