Stefan,
> What about querying "base:" if the NBD spec adds more standard metadata
> contexts in the future? "base:" does not "uniquely identify a server
> implementation" but it should still be possible to query it so that
> additional contexts can be added to this spec in the future.
>
> Is the query matching algorithm defined anywhere? I guess it is
> strncmp(query, context, strlen(query)) but I'm not sure from this text.
>
> Another common syntax would use an asterisk wildcard ('*') so that it's
> possible to differentiate between full matches and (wildcard) partial
> matches.I agree. I have suggested a simple string-based left match, which also fixes ... >> + - third-party implementations can register additional >> + namespaces by simple request to the mailinglist. > > Does this mean it is possible to activate multiple contexts but only if > their namespace is identical? That seems like an arbitrary limitation. > > In other words, the spec suggests you can activate nbd-server:a and > nbd-server:b but you cannot activate base:a and nbd-server:a. ... this, provided that NBD_SET_META_CONTEXT actually takes a list of query strings. > I'd prefer a programming model where the contexts don't need to be set > for the lifetime of the connection. Instead the client passes a bitmap > (64-bits?) of contexts along with each BLOCK_STATUS command. That way > the client can select contexts on a per-command basis. It's unlikely > that more than 64 contexts need to be available at once but I admit it's > an arbitrary limitation... > > I guess you've considered this model and decided it's better to > negotiate upfront, it's wasteful to enable multiple contexts and then > discard the response data on the client side because only a subset is > needed for this command invocation. The issue is that there's nowhere within the current command structure to put it. I think the easy way to do this would be to have context IDs as a payload to the command, like they are with NBD_CMD_WRITE, but the payload is currently always defined to be of the length specified within the length section. The question really is whether we should fix this silly protocol limitation. I don't think it's as bad as the structured reply fix, and could conceivably go in there. -- Alex Bligh
signature.asc
Description: Message signed with OpenPGP using GPGMail
