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

[Vladimir Sementsov-Ogievskiy <vsementsov@...2319...>]

14.12.2016 21:17, Alex Bligh wrote:

On 14 Dec 2016, at 17:55, Vladimir Sementsov-Ogievskiy <vsementsov@...2319...> wrote:

Hmmm... Well in the '*' case, it's up to the namespace as to how it parses things, so '*' could be prohibited entirely or mean 'return the first 20 matching' or similar. So that's less of a problem. And 'set all' doesn't exist (unlike 'list all').

I think in the LIST case we should allow the server to omit contexts under certain circumstances, and allow SET to return ETOOBIG.

We can't prohibit '*' as query string as implementation defined. And we shouldn't (I think) define its meaning.

Those two statements appear to me to contradict each other. The current documentation *does* define the query string (to the right of the colon) as implementation defined. I'm thus not sure what you mean.

Opposite, we can define, that query must not select more than 20 contexts, but I'm not sure that this is good.

Each query can select from only one namespace in the current document (Wouter explained why). However, you can specify multiple queries.

I don't think we need to define a hard limit of a particular number.

So, do you mean

 list('backup:modtime>*') -> empty list

The result of that would depend on however the 'backup' context was defined, meaning it had the options of:
* ETOOBIG
* Listing some subset of available contexts (arguably 'none' is a subset)

 set('backup:modtime>*') -> ETOOBIG

Again, the result of that would depend on however the 'backup' context was defined, meaning it had the options of:
* ETOOBIG
* Listing some subset of available contexts (arguably 'none' is a subset)
... and it need not make the same choice as above, but I agree it would be logical for it to do so.

As any form of wildcarding within a query refers to one particular namespace (as a query by its nature specifies a single namespace), we don't have to worry about the way wildcarding works in the standard, as Wouter pointed out. We merely need to provide that ETOOBIG and listing a subset are acceptable responses.

What we do need to decide is what the response to list() (i.e. a list with a zero length list of queries) does. It's currently defined to return every context from every namespace. Options would include
* ETOOBIG
* Listing some subset of available contexts (arguably 'none' is a subset)
* Allowing abbreviation of algorithmically specified contexts (e.g. in this case just returning 'backup:' to represent all available backup contexts)

Shouldn't we add some flags to REP_META_CONTEXT, for client to be insure, is returned string a direct context name or some kind of wildcard? Just a flags field, with one flag defined for now: NBD_REP_META_CONTEXT_LEAF and others reserved.

-- 
Best regards,
Vladimir