On Wed, Dec 14, 2016 at 06:51:48PM +0000, Alex Bligh wrote:
>
> > On 14 Dec 2016, at 18:18, Alex Bligh <a...@alex.org.uk> wrote:
> >
> > Let me have a go at a change.
>
> OK I've pushed a change. I reordered a few bits (to put the
> base:allocation next to the stuff that talks about metadata
> queries at the start), but the main change is below.
>
> --
> Alex Bligh
>
>
>
> @@ -970,15 +1029,38 @@ of the newstyle negotiation.
> - String, query to list a subset of the available metadata
> contexts.
>
> - 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`.
> -
> For details on the query string, see under `NBD_OPT_SET_META_CONTEXT`.
>
> 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:
> +
> + * the server MAY return an incomplete list if returning a
> + complete list would require undue resources.
This part is a bad idea, as per my other mail. Returning a complete list
should not be optional, but the definition of "complete" doesn't have to
imply "list all possible context names".
> + * 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.
> The metadata context ID in these replies is reserved and SHOULD be
> set to zero; clients MUST disregard it.
>
> @@ -1009,7 +1091,9 @@ of the newstyle negotiation.
>
> If zero queries are sent, the server MUST select no metadata contexts.
>
> - The server MUST reply with a number of `NBD_REP_META_CONTEXT`
> + The server MAY return `NBD_REP_ERR_TOO_BIG` if a request
> + seeks to select too many contexts. Otherwise
> + the server MUST reply with a number of `NBD_REP_META_CONTEXT`
This part makes sense.
> replies, one for each selected metadata context, each with a unique
> metadata context ID, followed by `NBD_REP_ACK`. The metadata context
> ID is transient and may vary across calls to `NBD_OPT_SET_META_CONTEXT`;
--
< ron> I mean, the main *practical* problem with C++, is there's like a dozen
people in the world who think they really understand all of its rules,
and pretty much all of them are just lying to themselves too.
-- #debian-devel, OFTC, 2016-02-12
