Subject: Re: [hybi] Comments on draft-loreto-http-bidirectional-01

From: Salvatore Loreto <[email-masked]>
Date: Tue, 09 Feb 2010 11:55:46 +0200

Hi Martin,

sorry to be late on this:

> ==Building an API:
>
> During Lisa's REST presentation yesterday, she noted that APIs aren't often done by the IETF.  Aside from the fact that these were pretty hard, her thesis was that APIs tend to build tight coupling and that they constrain implementations.  Based on this (and the fact that the W3C already does XMLHttpRequest) the API piece can be dropped.
>    
the hint within the draft is not to develop API within IETF, but to 
collaborate with W3C to exchange experiences and see what information 
would be interesting for them expose on their API.

    o  Possible improvements/extensions to XMLHttpRequest (XHR) API
       [W3C.WD-XMLHttpRequest2-20090820] to expose connection-handling
       details (e.g., use of pconns, pipelining, etc.)

/Sal

---

From: Greg Wilkins <[email-masked]>
Date: Tue, 09 Feb 2010 22:36:31 +1100

Salvatore Loreto wrote:
>> During Lisa's REST presentation yesterday, she noted that APIs aren't
>> often done by the IETF.  Aside from the fact that these were pretty
>> hard, her thesis was that APIs tend to build tight coupling and that
>> they constrain implementations.  Based on this (and the fact that the
>> W3C already does XMLHttpRequest) the API piece can be dropped.
>>    

How is that collaboration going to work?   Should we form a
rough consensus here and then communicate that to the W3C,
or should we give feedback individually to the w3c process.

Much of my feedback does depend on what we decide here
with regards to orderly close and timeouts:

Orderly close
-------------
if we have orderly close and error close, then
it would be good to indicate some status in the onclose
call back, so a websocket user/framework can handle
differently the cases of - a) can't connect via network
b) can connect, but permission denied c) was connected
but got disorderly disconnected d) was connected and
got orderly shutdown.

Idle timeouts
-------------
Websockets are going to be used to indicate presence.
eg if gregw has a websocket open to ws.freechat.org,
then it's indicating that I'm available to chat.

But if I don't chat for many hours, I still want to
be available.   Because idle connections can be closed,
somebody has to send some kind of keep alives.

This could be done by the application and/or framework,
but in order to be effective and efficient, it will
need some way to find out the negotiated timeout - perhaps
as an arg to the onopen callback.

Alternately, the browser could send the keep alives, but
then the app needs some way to indicate that it
wants the ws kept open and then when it wants it closed.

Both of these API changes need to be very carefully
thought out, because I do not think it is generally
wise to mix transport concerns with what is
essentially an application api.   For example, we
don't want any error status's or timeouts strengthening
the association with TCP/IP connections and thus making
any future multi-plexing harder.

My feeling is that we need to think through the protocol
implications of these kinds of things first before
giving any definitive feedback on the API

cheers

---

From: Maciej Stachowiak <[email-masked]>
Date: Tue, 09 Feb 2010 04:14:46 -0800

> giving any definitive feedback on the API

I agree. These issues should be resolved at the protocol level before we try to design the APIs. Of course, we should keep the API in mind when designing the protocol, and make sure we will be able to filter up the right information to clients.

Regards,
Maciej

---

From: Salvatore Loreto <[email-masked]>
Date: Tue, 09 Feb 2010 15:05:32 +0200

to be clear,
this particular mail thread is about HTTP long-polling requests,
and it has nothing to do with websocket.

To avoid present and future confusions,
I propose to move discussions about "classic" http-bidirectional, using 
HTTP long-polling or streaming, away from the HyBi ml.

What we are going to suggest in the next version of 
draft-loreto-http-bidirectional,
is to have any discussion on the draft in the IETF APP Area, in 
particular to the [email-masked] mailing list;
visit <https://www.ietf.org/mailman/listinfo/apps-discuss> for further   
information.

cheers
Sal