Re: [Qemu-devel] [Nbd] [PATCH] Further tidy-up on block status

[Alex Bligh <alex@alex.org.uk>]

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