Subject: [hybi] Don't cross the streams...

From: Mark Nottingham <[email-masked]>
Date: Tue, 31 Mar 2009 10:22:47 +1100

Can we get general agreement at this stage that we're really talking  
about two related but separate things here;

1) Work around "long polling" over HTTP (a la BOSH, Comet)

2) New protocols to address similar use cases (e.g., rHTTP,  
WebSockets; deliberately punting on listing the use cases for now)

and that trying to choose one approach/solution from these will be  
counter-productive?

Cheers,

P.S. This mailing list has 47 members at the moment, so I think we  
have some sort of a critical mass...

--
Mark Nottingham     http://www.mnot.net/

---

From: Ian Hickson <[email-masked]>
Date: Mon, 30 Mar 2009 23:39:57 +0000 (UTC)

On Tue, 31 Mar 2009, Mark Nottingham wrote:
> 2) New protocols to address similar use cases (e.g., rHTTP, WebSockets; 
> deliberately punting on listing the use cases for now)
> 

I agree entirely with this.

-- 
Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'

---

From: Michael Davidson <[email-masked]>
Date: Mon, 30 Mar 2009 17:52:43 -0700

By way of introduction: I'm new to this dicussion (and standards lists in
general), but I have worked on Google's proprietary Comet implementation
(used, among other places, in Gmail) and am generally interested in seeing
better support for server push integrated into browsers.

> I agree entirely with this.

Can you clarify a bit? This mailing list is intended to discuss both, and
standards for both? I'm not sure what "work around" means in the first case.
Is WebSockets intended to replace long polling? (Seems to me that it
certainly could.) Or is the intent to define standards around long polling
so that it's easier to write a Comet implementation? Is the focus client
side, server side, or both?

Michael

---

From: Ian Hickson <[email-masked]>
Date: Tue, 31 Mar 2009 01:18:34 +0000 (UTC)

On Mon, 30 Mar 2009, Michael Davidson wrote:
> Can you clarify a bit? This mailing list is intended to discuss both, 
> and standards for both? I'm not sure what "work around" means in the 
> first case. Is WebSockets intended to replace long polling? (Seems to me 
> that it certainly could.)

I think that on the long term we'll see authors migrate to using a 
dedicated Web-aware socket-based system when they want a two-way socket 
from a Web page.

However, on the short term, such solutions simply don't work, since 
they're not implemented and they rely on native support. The requirements 
for "long polling" systems are that they must work with today's UAs. Thus, 
it makes sense for both to exist.

> Or is the intent to define standards around long polling so that it's 
> easier to write a Comet implementation?

I don't have an opinion on this.

> Is the focus client side, server side, or both?

For Web-aware socket-based systems, both are important.

---

From: Peter Saint-Andre <[email-masked]>
Date: Mon, 30 Mar 2009 19:30:11 -0600

> and that trying to choose one approach/solution from these will be

Agreed.

Peter

-- 
Peter Saint-Andre
https://stpeter.im/

---

From: Michael Davidson <[email-masked]>
Date: Mon, 30 Mar 2009 19:01:49 -0700

On Mon, Mar 30, 2009 at 6:26 PM, Maciej Stachowiak <[email-masked]> wrote:

> Is there a need for a new standard related to "long polling" and making it
> work in today's UAs? If so, who would be the audience? I assume it would not
> be UA implementors, since anything that required UA changes would not work
> in today's UAs by definition. Is the document intended to describe a set of
> techniques that work across today's UAs?
>

I infer from Ian's above mail that this list is meant to discuss WebSockets,
i.e. the Comet of the future, and not techniques that work with today's UAs.

 Clearly both will continue to exist for the foreseeable future.

Michael

---

From: Ian Hickson <[email-masked]>
Date: Tue, 31 Mar 2009 02:13:24 +0000 (UTC)

On Mon, 30 Mar 2009, Michael Davidson wrote:
> > Is there a need for a new standard related to "long polling" and 
> > making it work in today's UAs? If so, who would be the audience? I 
> > assume it would not be UA implementors, since anything that required 
> > UA changes would not work in today's UAs by definition. Is the 
> > document intended to describe a set of techniques that work across 
> > today's UAs?
> 
> I infer from Ian's above mail that this list is meant to discuss 
> WebSockets, i.e. the Comet of the future, and not techniques that work 
> with today's UAs.

It was not my intent to dismiss other techniques; on the contrary, if 
there is a desire to discuss those techniques here I think that should 
definitely happen.

---

From: Lisa Dusseault <[email-masked]>
Date: Tue, 31 Mar 2009 14:23:00 -0700

I would like to see the current techniques described.  I think there's
enough variation in approaches, possibilities for advertising
capabilities, and similar niggles, that even if we can roughly
describe the idea behind "long-poll" in just a few sentences, we can
still make it work better with some documentation.

Lisa

On Mon, Mar 30, 2009 at 7:13 PM, Ian Hickson <[email-masked]> wrote:
> _______________________________________________
> hybi mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/hybi
>

---

From: Lisa Dusseault <[email-masked]>
Date: Tue, 31 Mar 2009 14:25:41 -0700

I forgot to mention, I hope the sockets approaches get documented too
-- my initial finger-in-the-air estimate is that there's enough
interest.  I see no reason why both purposes can't cohabit the same
list at this point, but if the topic does get too large, we can fork
the list.

Lisa