[webkit-dev] platform-specific differences in test case inputs

Adam Barth abarth at webkit.org
Tue Sep 18 12:50:25 PDT 2012


Where do you test that property?

Adam


On Tue, Sep 18, 2012 at 12:43 PM, Oliver Hunt <oliver at 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 <abarth at 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 <alecflett at 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 at lists.webkit.org
>>> http://lists.webkit.org/mailman/listinfo/webkit-dev
>>>
>> _______________________________________________
>> webkit-dev mailing list
>> webkit-dev at lists.webkit.org
>> http://lists.webkit.org/mailman/listinfo/webkit-dev
>


More information about the webkit-dev mailing list