- From: Chris Lilley <chris@w3.org>
- Date: Thu, 6 Apr 2006 14:54:01 +0200
- To: www-svg@w3.org
- Cc: Ian Hickson <ian@hixie.ch>
Hello www-svg, Ian Hickson <ian@hixie.ch> wrote: >> > The mediaContentEncodings attribute does not appear to require any >> > behaviour on the part of a renderer, although it hints at possible uses. >> >> We were not sure what you meant by that. If the size was measured with >> one media content encoding and the content arrives with a different >> media content encoding then clearly the prefetch hint is stale and >> cannot be used. > > There is no requirement that the prefetch hint be used at all. That follows from the fact that it is called a hint. Its extra information, which may optionally be used to give a better user experience. There is no requirement to perform prefetching; and if it is performed, these attributes are one information source that allows the user agent to make good choices. There might be other sources of information - for example the user agent might be throttled to reserve more bandwidth for a different application, or conversely it might be i a mode where it fetches everything that is linked and caches it in preparation for a period of offline use. > In fact, as > I mentioned, the mediaContentEncodings attribute does not appear to > require any behaviour at all on the part of a renderer. As mentioned in our earlier responses, these attributes allow detection of stale prefetch data. If the remote resource has been modified since the content with the prefetch was created - different size, different encoding, etc) then the user agent should not consider the prefetch data to be reliable. > Please clarify the specification so that it is clear what rendering UAs > may or must not do with these attributes. They may use the prefetch data to avoid startup delays and they may have other sources of information besides this data and they should not consider prefetch data which is found to be stale. > One way to do this would be to > include a clear subsection giving the processing model for this element, > giving the algorithm that must be used That would seem to preclude other algorithms that might be better suited to local situations. Two such scenarios (throttling, and cache filling) were mentioned above. We certainly don't want to preclude that. > to determine how much content to > prefetch, and then requiring (or allowing) the user agent to perform the > relevant network requests. Allowing works; requiring does not. > Currently this section vaguely mentioned > possibilities but makes no testable normative requirements on rendering > user agents. Testing this would require instrumenting the user agent, so that it reported back how much data was fetched and whether the hints were stale; also telling it to ignore any throttling or Quality of Service load balancing that was being performed, be the only application performing network requests, and so on. It would then certainly be possible to have some test cases with known correct prefetch data and others with known stale prefetch data; to verify that the stale data was correctly detected, and to verify that the correct amount of data had been prefetched. Its doable, for implementors, but not suitable for end-user testing. -- Chris Lilley mailto:chris@w3.org Chair, W3C SVG Working Group W3C Graphics Activity Lead Co-Chair, W3C Hypertext CG
Received on Thursday, 6 April 2006 12:54:01 UTC