Mailing-List: contact dev-help@couchdb.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@couchdb.apache.org
Received-SPF: pass (nike.apache.org: domain of paul.joseph.davis@gmail.com
 designates 209.85.214.180 as permitted sender)
DomainKey-Signature: a=rsa-sha1; c=nofws;
        d=gmail.com; s=gamma;
        h=mime-version:in-reply-to:references:from:date:message-id:subject:to
         :content-type:content-transfer-encoding;
        b=FxUohXm0beNkkYocTFkRX56eOkC8fdMNfm+CO12yroXB1Zqnu5TAf9vWKtWMrG+FL1
         cEbm/NQDSxml0cvJyzAkAt8tqKbZ+beZ1V1gMHR4GLV1l4ykSFeynBk1Cv6j4XEVRfsQ
         JCsSi2PBsk069HkhZzxDkkcHZbuHyiVkNpXF0=
MIME-Version: 1.0
In-Reply-To: <FAA4C3EE-5DCF-4B6C-A241-EDC8CDE85C00@googlemail.com>
References: <24334637.310951285054233138.JavaMail.jira@thor>
 <30053234.311391285056572830.JavaMail.jira@thor>
 <AANLkTim7wf1HmrUZDtJXknmXdeZBS1LdWqxod3sH-DGi@mail.gmail.com>
 <FAA4C3EE-5DCF-4B6C-A241-EDC8CDE85C00@googlemail.com>
From: Paul Davis <paul.joseph.davis@gmail.com>
Date: Fri, 1 Oct 2010 18:16:06 -0400
Message-ID: <AANLkTi=uz3=DbfnYOZnyKa+-1-foo_REXH4a=jPHUW31@mail.gmail.com>
Subject: Re: [jira] Commented: (COUCHDB-891) Allow ?keys=["a","b"] for GET to
 _view and _list
To: dev@couchdb.apache.org
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

I'm not unsympathetic to the concern, but there's already a few ways
to do other things. For instance, ever since we removed _bulk_docs
transaction semantics there's no actual reason to keep it around, but
we do. The might break as URI gets too long part I think is balanced
out by the benefits of things like being able to cache GET's and such
forth.

HTH,
Paul Davis

On Tue, Sep 21, 2010 at 10:01 AM, Sebastian Cohnen
<sebastiancohnen@googlemail.com> wrote:
> I'm not sure if I like the idea of having two ways accessing one function=
ality. One that will always work and one, that might or might not work, dep=
ending on the input (size).
>
> On 21.09.2010, at 15:55, Zachary Zolton wrote:
>
>> You're also better off caching GET requests than POST requests, should
>> the need ever arise.
>>
>> On Tue, Sep 21, 2010 at 3:09 AM, Michael Fellinger (JIRA)
>> <jira@apache.org> wrote:
>>>
>>> =A0 =A0[ https://issues.apache.org/jira/browse/COUCHDB-891?page=3Dcom.a=
tlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentI=
d=3D12912874#action_12912874 ]
>>>
>>> Michael Fellinger commented on COUCHDB-891:
>>> -------------------------------------------
>>>
>>> If you don't know the size of the keys, you can use POST, I'm not advoc=
ating this as a replacement, but as an alternative.
>>> My typical usage is to lookup up to a handful of keys, of known size, t=
hat fit comfortably in any URI.
>>>
>>> I recently hit an issue while trying to implement a _list document for =
FreeSWITCH (FS) configuration, that is queried directly.
>>> Unfortunately, i cannot redirect or rewrite the request for a _list wit=
h keys via POST, and I cannot modify the way FS does its queries, so I had =
to put a middleware in front just to handle this query for me.
>>> With GET, it would be trivial to handle this case, I'd leave it to the =
developer to decide whether to use GET or POST.
>>>
>>>> Allow ?keys=3D["a","b"] for GET to _view and _list
>>>> ------------------------------------------------
>>>>
>>>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 Key: COUCHDB-891
>>>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 URL: https://issues.apache.org/jira/br=
owse/COUCHDB-891
>>>> =A0 =A0 =A0 =A0 =A0 =A0 Project: CouchDB
>>>> =A0 =A0 =A0 =A0 =A0Issue Type: New Feature
>>>> =A0 =A0 =A0 =A0 =A0Components: HTTP Interface
>>>> =A0 =A0Affects Versions: 1.0.1
>>>> =A0 =A0 =A0 =A0 Environment: -
>>>> =A0 =A0 =A0 =A0 =A0 =A0Reporter: Michael Fellinger
>>>> =A0 =A0 =A0 =A0 =A0 =A0Priority: Minor
>>>> =A0 =A0 =A0 =A0 =A0 =A0 Fix For: 1.0.2
>>>>
>>>>
>>>> The idea was already described back in 2008 when the POST {"keys":["ke=
y1","key2"]} API was introduced.
>>>> http://mail-archives.apache.org/mod_mbox/couchdb-dev/200811.mbox/%3C49=
10D88A.8000809@kore-nordmann.de%3E
>>>> I'm looking at the source right now, but can't figure out how to imple=
ment this at the moment, and I'd love this to be part of CouchDB proper.
>>>
>>> --
>>> This message is automatically generated by JIRA.
>>> -
>>> You can reply to this email to add a comment to the issue online.
>>>
>>>
>
>