Subject: Re: [hybi] Who's buy-in we need

From: Simone Bordet <[email-masked]>
Date: Sun, 1 Aug 2010 14:03:19 +0200

Hi,

On Sat, Jul 31, 2010 at 19:37, Adam Barth <[email-masked]> wrote:
> On Sat, Jul 31, 2010 at 12:21 AM, Greg Wilkins <[email-masked]> wrote:
>> Besides, I think that  the IETF process needs to participation of the
>> browser vendors to be able to create any meaningful protocol.    Also, the
>> browser vendors need buy-in from server-side, intermediary and other
>> interests that are represented in the IETF.
>>
>> Together we can do something. Apart we are all just pissing in the wind.
>
> In all honesty, getting buy-in from browser vendors is much more
> important than getting buy-in from server operators or (especially)
> from intermediaries.  It might be a pleasant fiction to imagine that
> we should consider everyone's input equally, but that's not actually
> the best strategy for actually getting wide adoption.
>
> Imagine that browser vendors ignore feedback from server operators and
> intermediaries and plow ahead with whatever they think is best.  If
> they do a even a half-decent job, WebSockets will provide an
> attractive value proposition for web developers.  If the protocol is
> trivially implementable, web developers will stand up custom WebSocket
> servers on their EC2 servers and folks like Ruby-on-Rails will add
> support to their frameworks.

Imagine a protocol that breaks intermediaries in its current format.
If I would have asked to technically choose if to use WebSocket to
develop a new application to deploy over the internet (the best
tic-tac-toe ever written), knowing that WebSocket breaks for many
users just because they pass through an intermediary, or if to use
Comet that instead will work in all cases, then I would choose Comet.
And this will limit WebSocket adoption, no matter its support in browsers.

> As a point of reference, compare that story with the history of comet.
>  I think you'll agree that no sane person would advocate for comet
> being a reasonable protocol.  However, browser vendors shipped the
> necessary components (perhaps unwittingly), and folks like Alex
> Russell [1] figured out how to cobble together the pieces, and comet
> has achieved quite broad adoption.
>
> You're welcome to alienate browser vendors from this working group,
> but the net result will be that the working group has much less impact
> on the world.  Now, if you let Ian dictate the entire protocol, the
> working group also won't have any impact, so there's some balance to
> strike.
>
> The path to success for this working group, in my opinion, is to
> understand the desires and requirements of browser vendors and to
> design a protocol that meets those requirements better than the
> current draft.  That means, for example, you should listen carefully
> to what Mike Belshe, Rob Sayre, Maciej Stachowiak, and Anne van
> Kesteren say.  They form an important constituency.

Sure they do. They are all world-class developers.

But what are exactly the desires and requirements ?
I would say to make life easier for application developers, not to
make those world-class implementors life easier, as they surely can
grok UTF-8 counting and much more than that.

Application developers are currently exposed to the WebSocket procotol
on the server, not on the client.
On the client, application developers have an API that has not been
touched a bit, despite draft 75 and 76 are quite different.
Application developers are well served on the client, but kind of left
alone on the server.

I would respectfully say that the what Greg Wilkins, Scott Ferguson
and all other server-side "representatives" say is equally important,
and so is understanding their desires and requirements.

What we should really strive for, IMHO, is an efficient protocol as
simple as possible, but no simpler.
This is because API layers exist in the client and I expect equivalent
API layers to born on the server, exactly to shield the application
developers of the gory details (for example, in CometD the server-side
WebSocket API has not changed a bit between 75 and 76).

Simon
-- 
http://bordet.blogspot.com
---
Finally, no matter how good the architecture and design are,
to deliver bug-free software with optimal performance and reliability,
the implementation technique must be flawless.   Victoria Livschitz

---

From: Ian Fette (イアンフェッティ) <[email-masked]>
Date: Sun, 1 Aug 2010 05:12:29 -0700

> WebSocket API has not changed a bit between 75 and 76).

We seemed to make a lot of progress at the F2F on Friday, and it seems like
most people on the list are headed towards consensus on many issues - we
will find out over the next week. I would suggest that we keep making
progress and push ahead along the timelines discussed in Maastricht. I don't
think that debating the relative importance of browser vendors or server
vendors or intermediaries is really going to help us right now, let's stay
focused on the issues and on making progress, and we can decide the issues
based on the merits of the arguments presented.

-Ian

> _______________________________________________
> hybi mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/hybi
>

---

From: Christopher Blizzard <[email-masked]>
Date: Tue, 03 Aug 2010 14:45:26 -0700

On 7/31/2010 11:02 AM, Salvatore Loreto wrote:
> (unfortunately people from Mozilla were unable to attend this time, 
> and there were nobody from Apple) 

I met with Joe ahead of the meeting as I had to leave town before the 
day of the hybi meeting - I was able to express how we felt about the 
current situation with the spec.

--Chris