Re: [hybi] Adding clarification regarding future revisions (Was: Proposed way forward for WebSockets)

[Jamie Lokier <[e-mail]>]

Ian Hickson wrote:
> > And BTW, saying "Upgrade: WebSocket/1.0" would be *a lot* better than 
> > "Upgrade: WebSocket".
> 
> Not having a version field is intentional. Versioning is an anti-pattern 
> on the Web.

That statement is too opaque: it needs a reference or something.

I don't know what Ian means, but it might be this: In the Javascript
browser world, everyone is told to *avoid* browser version checks and
to check for *feature presence* instead.

But here's the thing: *Using* version numbers is the anti-pattern,
not *providing* them.

Browser version checks are a major anti-pattern, especially the awful
ones which do pattern matching on User-Agent, because they prevent new
browsers from changing anything that existing scripts check for.

Feature checks work quite well in browser JavaScript: Often the
presence of an object or attribute is enough.  It's not great though:
Implementations of XmlHttpRequest still vary enormously, for example.
So almost everyone sticks to a de facto common subset that work in the
big browsers, or they combine it with dodgy "existence of feature A
implies feature B works like blah because the big browsers have that
combination of behaviours".  Thus feature checks have problems too.

Then there's HTTP: version numbers in HTTP aren't reliable.  Quite a
few HTTP things advertise HTTP/1.1 but are not 1.1 complient.  Thus
you cannot trust the HTTP version, and if you care and if you can,
look for other hints that say what not to trust.

So neither versions nor detectable feature are reliable or trustable
in a large ecosystem where something deployed and buggy may need to be
supported anyway.

In general if a buggy implementation becomes widespread, you can't
trust what it says whether it's a version or feature string, and you
need whatever clues you can get to detect the buggy thing.

Version numbers, feature lists and user-agent style strings are all
useful clues when you have to cope with buggy things out there.

If there are no clues, that's an anti-pattern.

Concluding:

  - *Using* version numbers and user-agent strings instead of
    explicit feature checks is an anti-pattern because it blocks
    updates to those numbers and strings and forces them to lie.

  - But *not providing them* is an anti-pattern because it
    prevents workarounds and thus blocks deployment of new features.

Neither extreme is effective.

-- Jamie