> On 14 Dec 2016, at 17:55, Vladimir Sementsov-Ogievskiy
> <vsement...@virtuozzo.com> 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
