IETF Logo Mail Archive

Re: [hybi] Extensibility mechanisms?

Roberto Peon <fenix@google.com> Mon, 19 April 2010 15:45 UTC

Return-Path: <fenix@google.com>
X-Original-To: hybi@core3.amsl.com
Delivered-To: hybi@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 13F633A6B4D for <hybi@core3.amsl.com>; Mon, 19 Apr 2010 08:45:30 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -101.442
X-Spam-Level:
X-Spam-Status: No, score=-101.442 tagged_above=-999 required=5 tests=[AWL=0.534, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8oebAK6xKk+5 for <hybi@core3.amsl.com>; Mon, 19 Apr 2010 08:45:29 -0700 (PDT)
Received: from smtp-out.google.com (smtp-out.google.com [74.125.121.35]) by core3.amsl.com (Postfix) with ESMTP id D08173A6A97 for <hybi@ietf.org>; Mon, 19 Apr 2010 08:22:26 -0700 (PDT)
Received: from hpaq13.eem.corp.google.com (hpaq13.eem.corp.google.com [10.3.21.13]) by smtp-out.google.com with ESMTP id o3JFMHeY031232 for <hybi@ietf.org>; Mon, 19 Apr 2010 17:22:17 +0200
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1271690537; bh=SFCUMqsCyTsOZeCoF/yE4bS5vxs=; h=MIME-Version:In-Reply-To:References:Date:Message-ID:Subject:From: To:Cc:Content-Type; b=GqxmpMcPeHqeDpYaykxWORzO62xyFz0mZYKscX3CY/p3h1uWwXtxBoJzbWYJlK8+C wzIGNKDsoOUAssX1dF61w==
DomainKey-Signature: a=rsa-sha1; s=beta; d=google.com; c=nofws; q=dns; h=mime-version:in-reply-to:references:date:message-id:subject:from:to: cc:content-type:x-system-of-record; b=iYEu9nv7r3fi64vWBwz4KQW0cCuQsj856GMY1rK2OPAMQWfrWF376W6rZuyIwh5hd M4uOKUPmHG35yAtdifdtA==
Received: from qyk32 (qyk32.prod.google.com [10.241.83.160]) by hpaq13.eem.corp.google.com with ESMTP id o3JFLrsG025253 for <hybi@ietf.org>; Mon, 19 Apr 2010 17:22:16 +0200
Received: by qyk32 with SMTP id 32so4707188qyk.12 for <hybi@ietf.org>; Mon, 19 Apr 2010 08:22:15 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.229.191.202 with HTTP; Mon, 19 Apr 2010 08:22:15 -0700 (PDT)
In-Reply-To: <4BCC204D.30004@gmx.de>
References: <h2w5c902b9e1004152345j992b815bz5f8d38f06a19181a@mail.gmail.com> <4BCAB2C1.2000404@webtide.com> <B9DC25B0-CD21-44E7-BD9B-06D0C9440933@apple.com> <4BCB7829.9010204@caucho.com> <Pine.LNX.4.64.1004182349240.751@ps20323.dreamhostps.com> <4BCC0A07.9030003@gmx.de> <Pine.LNX.4.64.1004190753510.23507@ps20323.dreamhostps.com> <4BCC111C.90707@gmx.de> <Pine.LNX.4.64.1004190837570.23507@ps20323.dreamhostps.com> <4BCC204D.30004@gmx.de>
Date: Mon, 19 Apr 2010 08:22:15 -0700
Received: by 10.224.96.199 with SMTP id i7mr1718392qan.354.1271690535595; Mon, 19 Apr 2010 08:22:15 -0700 (PDT)
Message-ID: <z2gad99d8ce1004190822ne4dd36b6v54d63efcc448e840@mail.gmail.com>
From: Roberto Peon <fenix@google.com>
To: Julian Reschke <julian.reschke@gmx.de>
Content-Type: multipart/alternative; boundary="00c09f89978ba3702e048498862e"
X-System-Of-Record: true
Cc: Hybi <hybi@ietf.org>
Subject: Re: [hybi] Extensibility mechanisms?
X-BeenThere: hybi@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Server-Initiated HTTP <hybi.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/hybi>, <mailto:hybi-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/hybi>
List-Post: <mailto:hybi@ietf.org>
List-Help: <mailto:hybi-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/hybi>, <mailto:hybi-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 19 Apr 2010 15:45:30 -0000

On Mon, Apr 19, 2010 at 2:20 AM, Julian Reschke <julian.reschke@gmx.de>wrote:

> On 19.04.2010 10:48, Ian Hickson wrote:
>
>> There are many many implementations of HTTP. Some fast, some not so.
>>> Some complete, some not so.
>>>
>>
>> I think we can get orders of magnitude more complete implementations of
>> Web Sockets than of HTTP if we keep the protocol trivial.
>>
>
> Yes. That's a given. Make it less complex, and it will be easier to
> completely implement.


This isn't true! Make it (the protocol) less complex and it will be easy to
implement something which *conforms to the spec*, but not necessarily
something which scales and is robust, reliable, and scalable in the face of
all the stuff that happens out there.

The latter part is what really worries me. We really need to be sure that
the protocol that we create allows for an implementation of a server to do
these things. If the (hopefully small) added complexity is too much for the
amateur programmer, then they should use the API level. If we don't focus on
these things, we'll vastly increase the cost of infrastructure while
decreasing reliability. I don't see that as a positive tradeoff.
-=R


>
>  The main reason we see two server implementations rule the market isn't
>>> necessarily because of protocol complexity, but because one of them
>>> ships with a popular server platform, and the other one is free and
>>> "good enough" for almost everything.
>>>
>>
>> That is one possibility. I do not personally think it is the real reason.
>> Unfortunately, I don't know of any way to test these hypotheses.
>>
>
> OK. So let's get back to on-topic discussions.
>
> Best regards, Julian
>
> _______________________________________________
> hybi mailing list
> hybi@ietf.org
> https://www.ietf.org/mailman/listinfo/hybi
>

v2.23.0 | Report a Bug | By Email