Re: Indicating XHR conformance

On 2006/05/10, at 1:04 PM, Jim Ley wrote:
>> What would you recommend as an alternative?
>
> That authors write scripts without relying on such behaviour at  
> all.  This is what scripters have done for a long time.
> There are further problems with your example, it's no use if the  
> browser passes all HTTP caching and redirect tests, given that an  
> upstream proxy may or may not be involved which could change  
> behaviour, so a UA that passes the tests cannot be assumed to fully  
> work.

Of course the proxy -- and the server for that matter -- can do  
different things. That's not the point. Upstream caches are usually  
shared; a browser cache is private -- it's a different beast.  
Quantifying the behaviour of the HTTP stack end-to-end isn't my  
intention (nor is it a reasonable goal).

> Equally what is an author going to do if the cache is not supported  
> correctly?  They'll implement some other mechanism, in that  
> situation they might aswell just do that, so the checks are simply  
> redundant.

They may take remedial steps that would be more effectively handled  
by the browser. Having the ability to tell when you don't have to  
cache something (for example) because the browser will is quite  
valuable.

> Equally what does "pass all the tests" mean once new tests are  
> added?  So there must be individual feature strings for different  
> versions of test suites, and a UA will not be able to claim  
> conformance to any version of the test suite later than the  
> published date of the UA even if they do actually pass them.

The WG is going to publish one test suite for the purposes of CR.  
Being able to determine whether a UA meets those is better than nothing.

> Could you provide some actual use cases for such broken down  
> feature strings, I can't see any.

I'm presenting a number next week at XTech; I'll post here afterwards.

--
Mark Nottingham
mnot@yahoo-inc.com

Received on Wednesday, 10 May 2006 21:46:51 UTC