14.12.2016 22:01, Alex Bligh wrote: > Wouter, > > (Our mails crossed and I've actually pushed something, but no matter) > >> On 14 Dec 2016, at 18:49, Wouter Verhelst <w...@uter.be> wrote: >> >> What I was trying to say is that I think the result to _LIST_ with no >> queries should return all information the client needs to theoretically >> build the list of all possible contexts, even if that list may be >> so large as to be unfeasible for it to be built (e.g., in case of a >> cartesian product between all possible other contexts). I gave one >> example, but there may be more. >> >> My point is that if the query includes a namespace, the result should >> not be defined by our spec. If the query does not include a namespace, >> the result should be "complete" by whatever definition, but not >> unreasonable (i.e., don't just write a cartesian product to a client). >> >> This could allow an interactive client to present a user with a list of >> possible contexts before performing analysis on the block device, say. > OK, so first of all, one of the changes I made earlier was that now > each of the commands carries a list of queries, the way you list > everything is not 'having a query that doesn't contain a namespace' > but rather doing a _LIST_ with no queries at all. But that's semantics > and orthogonal to the main point. > > What I've proposed (and pushed - but feel free to alter it) is that
I think, an overview in "## Metadata querying" should be updated too. > > 1. on _LIST_, the server can return fewer contexts than are available > if returning all of them would consume undue levels of resources. > > 2. on _LIST_ where the contexts are 'algorithmic', the server can > return e.g. 'X-Backup:' rather than 'X-Backup:modified>' and > every integer. > > 3. On _SET_ if too many contexts are requested, the server may return > an error (I think we need this anyway). > > That nearly does what you ask for, but I'm not sure how you any query > could 'return all the information the client needs to build > the list of all possible contexts'. For instance, in my backup > example 'X-Backup:modified>[integer]' doesn't itself tell you > anything, as you don't know whether the integer is a unix > date time, in seconds after the epoch, milliseconds or whatever. > What, surely, as a client you want to know is 'does it support > the X-Backup: extension because I've read the spec for that and > know that it has X-Backup:modified if so'. So I've suggested it > return 'X-Backup:' only in that case, in which case from that > (*and the spec*) you know how to build any query. > -- Best regards, Vladimir ------------------------------------------------------------------------------ Developer Access Program for Intel Xeon Phi Processors Access to Intel Xeon Phi processor-based developer platforms. With one year of Intel Parallel Studio XE. Training and support from Colfax. Order your platform today.http://sdm.link/intel _______________________________________________ Nbd-general mailing list Nbd-general@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/nbd-general
