Re: NEW PREFERENCE - return=query-result

Ning Dong <> Sat, 03 October 2015 05:39 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id C9CA41ACCF4 for <>; Fri, 2 Oct 2015 22:39:01 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -6.312
X-Spam-Status: No, score=-6.312 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_45=0.6, RCVD_IN_DNSWL_HI=-5, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id KDAQ0M6wD6Vc for <>; Fri, 2 Oct 2015 22:38:59 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id C0B8B1A90DB for <>; Fri, 2 Oct 2015 22:38:59 -0700 (PDT)
Received: from lists by with local (Exim 4.80) (envelope-from <>) id 1ZiFTM-0008WM-Uu for; Sat, 03 Oct 2015 05:35:04 +0000
Resent-Message-Id: <>
Received: from ([]) by with esmtps (TLS1.2:DHE_RSA_AES_128_CBC_SHA1:128) (Exim 4.80) (envelope-from <>) id 1ZiFTI-0007CM-UV for; Sat, 03 Oct 2015 05:35:00 +0000
Received: from ([]) by with esmtps (TLS1.2:DHE_RSA_AES_128_CBC_SHA1:128) (Exim 4.80) (envelope-from <>) id 1ZiFTH-0000ix-Rt for; Sat, 03 Oct 2015 05:35:00 +0000
Received: from ([] helo=[]) by with esmtpsa (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.80) (envelope-from <>) id 1ZiFTH-0007EW-2a for; Sat, 03 Oct 2015 05:34:59 +0000
Mime-Version: 1.0 (Mac OS X Mail 9.0 \(3094\))
Content-Type: text/plain; charset="us-ascii"
To: James M Snell <>, Matthew Kerwin <>, "" <>
From: Ning Dong <>
In-Reply-To: <>
Resent-From: Yves Lafon <>
Date: Fri, 02 Oct 2015 21:05:01 +0000
Cc: Phil Hunt <>
Content-Transfer-Encoding: quoted-printable
Resent-Date: Sat, 03 Oct 2015 07:34:57 +0200
Message-Id: <>
X-Name-Md5: efe3dad792d606410c9cc49cedaffc94
References: <> <> <> <> <> <> <> <> <> <>
X-Mailer: Apple Mail (2.3094)
X-W3C-Hub-Spam-Status: No, score=-4.7
X-W3C-Hub-Spam-Report: ALL_TRUSTED=-1, AWL=-2.251, BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01, W3C_NW=0.5
X-W3C-Scan-Sig: 1ZiFTH-0000ix-Rt eddb9eb51891e4ee01dda46fe0f07b69
Subject: Re: NEW PREFERENCE - return=query-result
Archived-At: <>
X-Mailing-List: <> archive/latest/30317
Precedence: list
List-Id: <>
List-Help: <>
List-Post: <>
List-Unsubscribe: <>

   Is there more information that I should provide to get the proposed preference added?

   Besides sending email to this mailing list, do I need to do something else?



On 9/14/2015 11:01 AM, James M Snell wrote:
> The "transient" preference looks just fine to me.
> On Mon, Sep 14, 2015 at 10:59 AM, Ning Dong <> wrote:
>> Matt,
>>     Thanks for the comments.
>>     The proposed "transient" preference is a preference in the sense that
>> the server still can ignore it. In that case, the server would just create
>> the query definition. The client side will do the following:
>>     1. POST /searches (with body=query definition)
>>         Server returns something like:
>>         201 CREATED
>>         Location: /searches/foobar
>>     2. GET /searches/foobar/result
>>         to get the query executed and return the query result
>>     3. DELETE /searches/foobar
>>         A responsible client needs to delete the resource since it won't be
>> used any more.
>>     I agree that the "transient" preference alters the server behavior. I
>> think any preference header alters the server behavior in some way but I
>> think your concern is that this alters the most basic behavior of the server
>> (the basic part is creating the resource).
>>     We have been exploring different options of supporting the adhoc query
>> in a "standard" way. We could do the 3 steps way, but it is a lot of
>> overhead.
>>     We could enhance out specific media type and include "transient"
>> information inside the query definition itself in the payload. It works only
>> for our query definitions and won't work for other media types.
>>     (If we had SEARCH verb, it would solve our problem, but it has not been
>> approved yet.)
>>     I have been thinking whether this can be make more generic and applied
>> to broader scope instead of this narrow use case. Yes it is kind of related
>> to caching. Following that line of thought, would it make sense to do
>> something like?
>>     Prefer: time-to-live=0
>>     or
>>     Prefer: time-to-live=short (we can have other values like medium, long)
>>     BTW, this is the first time for me to send a request and discuss
>> something in this mailing list. Please let me know if there is a better
>> communication channel so that I don't pollute everybody's mailbox.
>>     Thanks a lot.
>> Ning
>> On 9/11/2015 8:06 PM, Matthew Kerwin wrote:
>> On 12/09/2015 9:14 AM, "Ning Dong" <> wrote:
>>> I submitted two requests, and both of them are related to search. If we
>>> have the SEARCH verb, then we don't have this problem.
>>> For the case where client wants to execute an ad hoc query against a
>>> collection, [...]
>>> We don't want to save the query definition though since it won't be
>>> useful. We really just want the server to use the query definition in the
>>> payload, execute query and return the result.
>>> A second use case is a query definition might be reused later, but we want
>>> the query to be executed when the query definition resource is created to
>>> save a server round trip. That is the return=query-result proposal. This use
>>> case is achievable with two requests: one to create the query definition
>>> resource, and another to execute the query.
>>> Thanks.
>>> Ning
>> The problem I'm having is that you're mixing things up strangely. The
>> endpoint definition seems to be: POST here to store a procedure. On top of
>> that you layer a preference for "also execute it and return the result." Ok,
>> I can understand that, and maybe 'query-result' is different enough from
>> 'representation' to make sense.
>> But with 'transient' you seem to instead be saying: the endpoint definition
>> is to store a query, and immediately execute it and return the result. On
>> top of that you're layering a preference to not store the query? It seems
>> quite convoluted, or at least not well engineered, and smells a bit like
>> server-side caching of requests.
>> If I'm reading it wrong, and it's actually the *same* endpoint (i.e. store
>> the query, and maybe return an immediate result) then 'transient' isn't a
>> preference, it's an instruction to alter the base behaviour of the endpoint
>> -- an instruction which should be signalled, not with a preference, but with
>> a mechanism like those I mentioned earlier.
>> Cheers