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

[Alex Bligh]

> On 14 Dec 2016, at 17:55, Vladimir Sementsov-Ogievskiy <address@hidden> 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)

-- 
Alex Bligh