Mailing-List: contact user-help@couchdb.apache.org; run by ezmlm
Precedence: bulk
Reply-To: user@couchdb.apache.org
Received-SPF: pass (nike.apache.org: local policy includes SPF record at
 spf.trusted-forwarder.org)
MIME-Version: 1.0
In-Reply-To: <C75C55A1-E168-4F1E-B9E6-61938CB5EB4A@couchbase.com>
References: 
 <CAPNuaCjSzBo7J_vfvAHnSwrr056wCVQSAeAX9kMuzeMs6+sAzA@mail.gmail.com>
	<F88E1DBF-2451-4F0B-8A79-5D61FE990E0F@couchbase.com>
	<CAPNuaChRra6rbohagtRSMUhUgbW-Ygj3Boq2mgxiMHSb0pghHA@mail.gmail.com>
	<C75C55A1-E168-4F1E-B9E6-61938CB5EB4A@couchbase.com>
Date: Wed, 6 Nov 2013 08:47:24 -0600
Message-ID: 
 <CAO1Qm-gVWb7Mvj6H6AJDanf9YB+--00g3Z5aJxODf7a0ekX_GQ@mail.gmail.com>
Subject: Re: Http 1.1 keep alive
From: "matt j. sorenson" <matt@sorensonbros.net>
To: user@couchdb.apache.org
Content-Type: multipart/alternative; boundary=089e0149ccae34977904ea833a3a

--089e0149ccae34977904ea833a3a
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: quoted-printable

On Tue, Nov 5, 2013 at 6:22 PM, Jens Alfke <jens@couchbase.com> wrote:

>
> On Nov 5, 2013, at 3:57 PM, Stanley Iriele <siriele2x3@gmail.com> wrote:
>
> > This snippet I found in the couchdb core api section of the documentati=
on
> > seems a bit misleading to me. It looks like its saying" keeping
> connections
> > is hard so tear them down=94..
>
> I agree, that quote is very misleading! It seems to be confusing
> =93connection=94 with =93request=94: HTTP requests are stateless, but the=
 network
> transport will reuse a TCP connection across multiple requests. Someone
> should rewrite it.
>
> The quote appears here:
>         http://docs.couchdb.org/en/latest/intro/api.html#revisions
> It appears at a lot of other URLs, says Google, but it seems to originate
> from the =93Complete Guide=94 book at http://guide.couchdb.org.
>
> =97Jens


So, statelessness is defined more at the application level (meaning
couchdb); and is fundamentally a pattern of RESTful interfaces - meaning
each request and response contains anything & everything necessary to
communicate application state... is that more/less correct? It's been quite
a few years since I *skimmed* Fielding's paper ;)

Where-as the http level stuff is more of a transport layer thing?

Perhaps I'm mis-using the OSI layer references[1] here, but logically it
helps me to think of the statelessness at a layer above, and
not-really-caring-about-or-impacted-by, the connection/keep-alive in the
protocol.

[1] http://en.wikipedia.org/wiki/OSI_model

--089e0149ccae34977904ea833a3a--