From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on dcvr.yhbt.net X-Spam-Level: X-Spam-ASN: AS15169 209.85.128.0/17 X-Spam-Status: No, score=-4.2 required=3.0 tests=AWL,BAYES_00, DKIM_ADSP_CUSTOM_MED,DKIM_SIGNED,DKIM_VALID,FREEMAIL_FORGED_FROMDOMAIN, FREEMAIL_FROM,HEADER_FROM_DIFFERENT_DOMAINS,HTML_MESSAGE,RCVD_IN_DNSWL_NONE, RCVD_IN_MSPIKE_H2,SPF_PASS shortcircuit=no autolearn=ham autolearn_force=no version=3.4.0 Received: from mail-pf0-f183.google.com (mail-pf0-f183.google.com [209.85.192.183]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by dcvr.yhbt.net (Postfix) with ESMTPS id 577212018E for ; Tue, 9 Aug 2016 03:10:19 +0000 (UTC) Received: by mail-pf0-f183.google.com with SMTP id i6sf145187pfe.0 for ; Mon, 08 Aug 2016 20:10:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlegroups.com; s=20120806; h=sender:date:from:to:message-id:in-reply-to:references:subject :mime-version:x-original-sender:reply-to:precedence:mailing-list :list-id:list-post:list-help:list-archive:list-subscribe :list-unsubscribe; bh=e9yNI1hptlcAbLhl3pma1Vdj8s27f5lhIryHpH6iC2U=; b=eZU4r+iSHoQ8g+SDN4vIP/82ucWIKz0pVgOJneYcRU5pEgpp3yAHkZSrlBonvXusFB yaDT/9QXc2yLnv5geSZGAgDK3qVk3i7SfV/2U+2CNCDYCkwBeLoJ28CTE5tck1d1ysiE 3B505JZXWNq8DVlSf9m8jBEk+rqIJ4AiuOoNNw16dmdeDMGVFoQhmqGDvunwSyBBmxMw u5qr3CIxDegTXfQLfE3e6gl2P1xNWjpE1fg90RB/8/JhsJRI9hq3htKgYWqTFds5QLkk zy7zWsGjp5UkY463t++D9tISAszEwlWmuQtJVB0BmsNL1nEWHprKLZwT45xhVwVMVIB5 YGPQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=sender:x-gm-message-state:date:from:to:message-id:in-reply-to :references:subject:mime-version:x-original-sender:reply-to :precedence:mailing-list:list-id:list-post:list-help:list-archive :list-subscribe:list-unsubscribe; bh=e9yNI1hptlcAbLhl3pma1Vdj8s27f5lhIryHpH6iC2U=; b=g2tgWIc9AaftJPvmntoN92U4mB92Y20NaCr0EUPgCPIfcgALn6nb0ia9iFSrYwoP52 Q6GqXwfAyGoP70G+pWl308xCx6E5GEhRWHtZcS8AesJXdy8X2T6zRjAYbmdX9eyMPmUd 3RL9DDnJKwOiFT2YYtdjZregEz0HqFgO0EPSIyDcMcN57oe6IvfsJLmCeYhIBfy0iO9B dzJe0rg/xRHdqYkf4/C4HmQB/0nAeFp0o5CoW1pJ130Kz74Wenkznd7sbWG2Kv3l3Lxm z5HqKQvFtTB6iuqFSji0R4d0n9Vk8IDj+sl83W5pwvQ7Pt4+pfj17K5ZweJq6CFD1cVK tytw== Sender: rack-devel@googlegroups.com X-Gm-Message-State: AEkoousEFaYIkGWoeSlzlfmU/sOJevALyLqhGOXK+7mR96RN8FrmjgeqtYS2sNvQE5Lv7A== X-Received: by 10.157.10.77 with SMTP id 71mr1961483otg.15.1470712218656; Mon, 08 Aug 2016 20:10:18 -0700 (PDT) X-BeenThere: rack-devel@googlegroups.com Received: by 10.157.17.91 with SMTP id p27ls8658733otp.2.gmail; Mon, 08 Aug 2016 20:10:18 -0700 (PDT) X-Received: by 10.237.44.38 with SMTP id f35mr82512265qtd.18.1470712218450; Mon, 08 Aug 2016 20:10:18 -0700 (PDT) Received: by 10.202.215.84 with SMTP id o81msoig; Mon, 8 Aug 2016 20:02:17 -0700 (PDT) X-Received: by 10.36.230.68 with SMTP id e65mr234140ith.1.1470711737662; Mon, 08 Aug 2016 20:02:17 -0700 (PDT) Date: Mon, 8 Aug 2016 20:02:17 -0700 (PDT) From: Samuel Williams To: Rack Development Message-Id: <9952888d-17b0-4a8b-8d61-29698fe28648@googlegroups.com> In-Reply-To: References: <24c6a373-ff9a-452d-bcce-6adaac37d5ad@googlegroups.com> <20160116012542.GA77422@TC.local> Subject: Re: HTTP2: Are we there yet? MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_Part_7693_1466700642.1470711737340" X-Original-Sender: space.ship.traveller@gmail.com Reply-To: rack-devel@googlegroups.com Precedence: list Mailing-list: list rack-devel@googlegroups.com; contact rack-devel+owners@googlegroups.com List-ID: X-Google-Group-Id: 486215384060 List-Post: , List-Help: , List-Archive: , List-Unsubscribe: , ------=_Part_7693_1466700642.1470711737340 Content-Type: multipart/alternative; boundary="----=_Part_7694_99731018.1470711737340" ------=_Part_7694_99731018.1470711737340 Content-Type: text/plain; charset=UTF-8 I've thought about these issues too. I don't think there is anything wrong with Rack. It could be tidied up a bit and it's good, IMHO, that it's entered maintenance mode. Not much needs to change IMHO. It's solid. Big changes here will only cause chaos. In my mind, HTTP2 is more about communication between client and front-end server. If the application server implements HTTP1 that's fine. Let's face it, in production we don't usually use Rack to serve static files, etc. Additionally, in my mind, an HTTP application server is no place for real-time communication. They are two separate concerns. For example, we have a real-time web chat system which implements a real-time run-loop using multiple event-driven reactors. It still communicates with a backend database using the same code as our application server, but it works in a way which can scale to 1000s of active connections per instance. I think that trying to shoehorn these orthogonal concerns into Rack is probably a bad idea in general and will just destroy the original beauty of `response = app.call(env)`. I'd prefer to see Rack evolve in a way which makes it better as an application server for request/response type workloads. If we need to augment that with something else, let's figure that out in a different framework? -- --- You received this message because you are subscribed to the Google Groups "Rack Development" group. To unsubscribe from this group and stop receiving emails from it, send an email to rack-devel+unsubscribe@googlegroups.com. For more options, visit https://groups.google.com/d/optout. ------=_Part_7694_99731018.1470711737340 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
I've thought about these issues too.

I don't think there is anything wrong with Rack. It could be tidied u= p a bit and it's good, IMHO, that it's entered maintenance mode. No= t much needs to change IMHO. It's solid. Big changes here will only cau= se chaos.

In my mind, HTTP2 is more about communic= ation between client and front-end server. If the application server implem= ents HTTP1 that's fine. Let's face it, in production we don't u= sually use Rack to serve static files, etc.

Additi= onally, in my mind, an HTTP application server is no place for real-time co= mmunication. They are two separate concerns. For example, we have a real-ti= me web chat system which implements a real-time run-loop using multiple eve= nt-driven reactors. It still communicates with a backend database using the= same code as our application server, but it works in a way which can scale= to 1000s of active connections per instance.

I th= ink that trying to shoehorn these orthogonal concerns into Rack is probably= a bad idea in general and will just destroy the original beauty of `respon= se =3D app.call(env)`.

I'd prefer to see Rack = evolve in a way which makes it better as an application server for request/= response type workloads. If we need to augment that with something else, le= t's figure that out in a different framework?

--

---
You received this message because you are subscribed to the Google Groups &= quot;Rack Development" group.
To unsubscribe from this group and stop receiving emails from it, send an e= mail to rack-dev= el+unsubscribe@googlegroups.com.
For more options, visit http= s://groups.google.com/d/optout.
------=_Part_7694_99731018.1470711737340-- ------=_Part_7693_1466700642.1470711737340--