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

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

> On 14 Dec 2016, at 20:18, Wouter Verhelst <w@uter.be> wrote:
> 
>> +    * the server MAY return a context consisting of a namespace and
>> +      a colon only (i.e. omitting the leaf-name) to indicate that
>> +      the namespace contains a large number of possible contexts
>> +      within that namespace (for instance a namespace `X-backup` with
>> +      contexts that indicate whether blocks were written after
>> +      a given date might accept queries of the form
>> +      `'X-backup:modifiedtime>[unixdate]'` where `[unixdate]` is an
>> +      arbitrary integer, and in this case it might simply
>> +      return `X-backup:`)
> 
> This is way too detailed, I think. It should just allow namespaces to
> define what _LIST_ may return, as long as the client is somehow able to
> distill (through knowledge of the spec as well as the information sent
> in reply to the _LIST_ command) all the metadata contexts it can
> possibly select.


OK, this part now reads:

    The server MUST either reply with an error (for instance `EINVAL`
    if the option is not supported), or reply with a list of
    `NBD_REP_META_CONTEXT` replies followed by `NBD_REP_ACK`.

    If zero queries are sent, then the server MUST return all
    the metadata contexts that are available to the client to select
    on the given export with `NBD_OPT_SET_META_CONTEXT`, save that:

    If one or more queries are sent, then the server MUST return
    those metadata contexts that are available to the client to
    select on the given export with `NBD_OPT_SET_META_CONTEXT`,
    and which match one or more of the queries given. The
    support of wildcarding within the leaf-name portion of
    the query string is dependent upon the namespace.

    In either case, however, for any given namespace the
    server MAY, instead of exhaustively listing every
    matching context available to select (or every context
    available to select where no query is given), send
    sufficient context records back to allow a client with
    knowledge of the namespace to select any context. Each
    namespace returned MUST still satisfy the rules for
    namespaces (i.e. they must begin with the relevant
    namespace, followed	by a colon, then printable non-whitespace
    UTF-8 characters, with the entire string not exceeding
    255	bytes). This may be helpful where a client can
    construct algorithmic queries. For instance, a client might
    reply simply with the namespace with no leaf-name (e.g.
    'X-FooBar:') or with a range of values (e.g.
    'X-ModifiedDate:20160310-20161214'). The semantics of
    such a reply are a matter for the definition of the
    namespace.

Hope that works.

-- 
Alex Bligh