[Webkit-unassigned] [Bug 38665] [chromium] Update chromium port to send/receive cached metadata

[bugzilla-daemon at webkit.org]

https://bugs.webkit.org/show_bug.cgi?id=38665





--- Comment #18 from Darin Fisher (:fishd, Google) <fishd at chromium.org>  2010-05-11 21:44:19 PST ---
> I will completely defer to your recommendation here. Basically this is just an identifier that has to survive a round trip in order to make sure the metadata gets stored with the correct cache entry. The fact that it is a responseTime is really an implementation detail. WebCore never actually touches this field.
> 
> So I could see looking at this as either (a) an opaque identifier in which case it could be renamed or (b) as a response time that just happens to be used as this identifier. Please let me know if you prefer I keep it as-is or static_cast it to a double and back. I'll upload the updated patch after we figure this out.

Converting 'long long' to/from 'double' just means that we can only have 52 bits of precision, right?  That seems plenty sufficient for this use case, right?

By the way, I actually had the same thought as you after submitting my comments.  It is attractive to view response-time as an opaque identifier.  That said, the response-time is actually a piece of information that would be useful to the cache expiration calculations performed by WebCore's memory cache.  Presently it just has to guess, which can lead to skewed results.  (Maybe it should really be set on ResourceResponseBase, or we can do that as a separate patch since other ports won't set it yet.)

Does the Chromium side require an exact match for the response-time to validate that the cached response is the same?  It probably is sensible for it to do so.  Anyways, I think it is safe to use double.  Note, on the Chromium side we have Time::ToDoubleT and FromDoubleT.

-- 
Configure bugmail: https://bugs.webkit.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.