On Wed, Feb 27, 2013 at 11:03 AM, Martin Thomson
<martin.thomson@gmail.com>wrote:
> On 27 February 2013 10:51, Roberto Peon <grmocg@gmail.com> wrote:
> > Then you can't do websockets, etc or whatever other protocol (maybe
> video?,
> > who knows) the web platform decides to do in the future on the same
> > socket/session.
>
> Not true. Write another RFC that says how you can share the
> connection with websockets. That might have to change some of the
> rules, loosen some of the constraints, add some features.
>
We have enough to do here without worrying about it, but there you go.
https://docs.google.com/document/d/1zUEFzz7NCls3Yms8hXxY4wGXJ3EEvoZc3GihrqPQcM0/edit
>
> > That would be a poor tradeoff.. and for what gain?
> > What is the additional complexity of having the framing allow for non
> HTTP
> > semantics?
>
> The cost is in building generality. Generality in engineering is
> never general enough to solve unforeseen problems, and it never ever
> comes with a zero complexity cost.
>
When I have a session with a client, I'd like to minimize my resource use,
and provide maximal bandwidth/memory prioritization so that the client's
experience is the best that I can give.
This is neither a theoretical nor insubstantial problem.
-=R