Wouter, (Our mails crossed and I've actually pushed something, but no matter)
> On 14 Dec 2016, at 18:49, Wouter Verhelst <w...@uter.be> wrote: > > What I was trying to say is that I think the result to _LIST_ with no > queries should return all information the client needs to theoretically > build the list of all possible contexts, even if that list may be > so large as to be unfeasible for it to be built (e.g., in case of a > cartesian product between all possible other contexts). I gave one > example, but there may be more. > > My point is that if the query includes a namespace, the result should > not be defined by our spec. If the query does not include a namespace, > the result should be "complete" by whatever definition, but not > unreasonable (i.e., don't just write a cartesian product to a client). > > This could allow an interactive client to present a user with a list of > possible contexts before performing analysis on the block device, say. OK, so first of all, one of the changes I made earlier was that now each of the commands carries a list of queries, the way you list everything is not 'having a query that doesn't contain a namespace' but rather doing a _LIST_ with no queries at all. But that's semantics and orthogonal to the main point. What I've proposed (and pushed - but feel free to alter it) is that 1. on _LIST_, the server can return fewer contexts than are available if returning all of them would consume undue levels of resources. 2. on _LIST_ where the contexts are 'algorithmic', the server can return e.g. 'X-Backup:' rather than 'X-Backup:modified>' and every integer. 3. On _SET_ if too many contexts are requested, the server may return an error (I think we need this anyway). That nearly does what you ask for, but I'm not sure how you any query could 'return all the information the client needs to build the list of all possible contexts'. For instance, in my backup example 'X-Backup:modified>[integer]' doesn't itself tell you anything, as you don't know whether the integer is a unix date time, in seconds after the epoch, milliseconds or whatever. What, surely, as a client you want to know is 'does it support the X-Backup: extension because I've read the spec for that and know that it has X-Backup:modified if so'. So I've suggested it return 'X-Backup:' only in that case, in which case from that (*and the spec*) you know how to build any query. -- Alex Bligh
