Re: [hybi] Framing take IV [why fragment]

[Jack Moffitt <[e-mail]>]

> The bulk of any websocket application will be on the server, just like the
> bulk of any HTTP application is on the server now. The bulk of application
> developers will be on the server, just like HTTP now. The bulk of the
> application complexity will be on the server.  Anything that makes the
> server application easier to develop is a benefit to the application.

I have to disagree with this. There are now many applications
springing up that have very minimal server requirements. Even more of
these applications have no 1st party server requirements (things like
Twitter clients, etc). We also have several frameworks (existing and
up and coming) that use web technology as the basis for application
development.

In my own projects, much of the work is on the client side. The server
exists only to store and forward data and to serve as an efficient
distribution system for the application itself.

Assuming WebSockets is successful, there will be frameworks akin to
Django and Rails that make doing the server side of WebSockets
extremely simple, and application developers can focus on the
frontend. I think that WebSockets has the potential to further this
trend of moving web browsers from dumb terminals into robust and
capable application platforms.

I'd like there to be some streaming API or at least an exposing of the
fragments all the way to JavaScript that could enable a more efficient
or different class of applications. Without these things, there *will*
be a lot of extra server side code to enable this in some cases. In
the world we live in now, we have XHR, which has all of these problems
and then some.

If anything, a chunk/streaming API would probably move even more
application logic to the client side, since more sophisticated things
would be possible.

jack.