Re: Accessible chat software

Marti wrote:
> 
> I have used a chat program that implements a server push -(actually flush()
> in PHP). The client side only sees the HTML so it works pretty well with
> screen readers - the big drawback is that some browser/platform combinations
> don't respond to the push.

Modern web servers should not react to flush, or should only do so if you
take positive steps to de-optimise them.

For dynamic content, a modern (HTTP 1.1) server, should either supply a
length for the whole response (requires the whole response be available
before any is returned) or should should break the response up into 
chunks, each of which has a defined length.  Very small chunks are
not a good thing, so I wouldn't expect a server to generate them.

If you deny the server these mechanisms, it cannot handle pipelined requests,
as there is no way for the client to identify where one response ends and
the next starts.

What you are doing is basically a hack relying on implementation details,
not on any defined behaviour for the HTTP protocol.  If you want a
real push, you must use a protocol that handles the push end to end.
For chat, these protocols are decades old, even though the "instant
messaging" branding of the feature is new.

(Note the technique also requires that tables not be used, or that you
restrict yourself to IE5 or better, and use style sheets to force 
incremental rendering of the table.)

Received on Sunday, 4 February 2001 08:37:38 UTC