So.
I understand (and share) the desire to keep things simple, but I think
this is a mistake.
We create extensions not only for people who implement the NBD protocol
today, but also for future implementors. As such, I want to make as few
as possible cases of "if you support feature A, you MUST also support
feature B", because it allows a possible misreading of the standard and,
as a result, implementation bugs.
In some cases this is unavoidable, of course. If you want to do STARTTLS
you must also implement newstyle negotiation; but this is obvious by the
fact that STARTTLS can be negotiated only by a newstyle negotiation, so
even if you read the spec less than carefully, you'll notice that
there's only one way to implement STARTTLS, and that is to implement
newstyle.
The same isn't true for this proposed change. The idea of "NBD_OPT_INFO"
is not implemented in terms of things provided by the block sizes
extension (rather, the reverse is true). As such, people may miss the
fact that if you say "get me some information on the export", you're now
suddenly *required* to also align requests to these block sizes sent in
the information replies. Worse, if we ever add a second extension that
requires the client to signal that it will abide by the stuff the server
laid out in NBD_REP_INFO messages, we suddenly have a situation where,
for historical reasons, you need to acknowledge and affirm the use of
one feature but not the other. This is going to confuse not only third
parties but, I'm sure, us as well.
In addition, while I understand the reasoning behind announcing block
sizes, I do not want to make "abiding by announced block sizes" a
prerequisite of "using the more modern way of choosing an export". The
protocol currently has no requirement for a server to use a particular
block size, and I think this is a feature. Sure, most clients *do*
currently request data in block-sized units, but that doesn't mean we
need to make that a requirement. A simple user-space client which wants
to inspect (and possibly modify) some parts of an export might not care
about block sizes; we should make writing such clients not harder than
needs be.
In that same light, I think we should discourage (but allow) the use of
NBD_REP_ERR_BLOCK_SIZE_REQD (although we might want to make that error's
name a bit shorter -- boy that's a lot of typing) in the same way that
we currently allow but discourage ENOMEM.
[...]
--
< ron> I mean, the main *practical* problem with C++, is there's like a dozen
people in the world who think they really understand all of its rules,
and pretty much all of them are just lying to themselves too.
-- #debian-devel, OFTC, 2016-02-12
Attachment:
signature.asc
Description: PGP signature