Re: [Nbd] [PATCHv5] docs/proto.md: Clarify SHOULD / MUST / MAY etc

[Wouter Verhelst <w@...112...>]

On Mon, Apr 11, 2016 at 01:37:27PM +0100, Alex Bligh wrote:
> Wouter,
> 
> Looks like Eric and I are both OK with this one (though Eric wants
> a follow-up patch which I think he has done elsewhere).
> 
> Is this OK by you?

Yeah, but it doesn't apply anymore (some churn since this patch was
sent):

Applying: docs/proto.md: Clarify SHOULD / MUST / MAY etc
.git/rebase-apply/patch:243: trailing whitespace.
      32 bits: error (MUST be non-zero)  
error: patch failed: doc/proto.md:25
error: doc/proto.md: patch does not apply
Patch failed at 0001 docs/proto.md: Clarify SHOULD / MUST / MAY etc

Obviously the trailing whitespace needs to be there, but other than
that...

Can you rebase?

> Alex
> 
> 
> On 7 Apr 2016, at 08:35, Alex Bligh <alex@...872...> wrote:
> 
> > Eric,
> > 
> >>> -    The server MUST NOT fail an NDB_OPT_GO sent with the same parameters
> >>> -    as a previous NBD_OPT_INFO which returned successfully (i.e. with
> >>> +    The server MUST NOT fail an `NDB_OPT_GO` sent with the same parameters
> >>> +    as a previous `NBD_OPT_INFO` which returned successfully (i.e. with
> >>>    `NBD_REP_SERVER`) unless in the intervening time the client has
> >>>    negotiated other options. The server MUST return the same transmission
> >>> -    flags with NDB_OPT_GO as a previous NDB_OPT_INFO unless in the
> >>> +    flags with `NDB_OPT_GO` as a previous `NDB_OPT_INFO` unless in the
> >>>    intervening time the client has negotiated other options.
> >> 
> >> I failed to notice this earlier, but a server MAY send different
> >> transmission flags if NBD_OPT_INFO(name1) is immediately followed by
> >> NBD_OPT_GO(name2), with no intervening client options (because some of
> >> the transmission flags, like read-only, are determined by the choice of
> >> export name). The first sentence gets this right ("with the same
> >> parameters"), the second does not (missing that phrase).
> >> 
> >>>    The values of the transmission flags MAY differ from what was sent
> >>>    earlier in response to an earlier `NBD_OPT_INFO` (if any), and/or
> >>>    the server MAY fail the request, based on other options that were
> >>>    negotiated in the meantime.
> >> 
> >> And if we reword the second sentence, the third sentence may also need a
> >> tweak.
> >> 
> >> However, it may be worth fixing that as a followup patch, and letting
> >> this one through.
> >> 
> >> Everything else is looking good from my perspective.
> >> 
> > 
> > I don't think I changed the meaning here (merely added backticks)
> > so I think this should be addressed separately.
> > 
> > I agree with the change though.
> > 
> > --
> > Alex Bligh
> > 
> > 
> > 
> > 
> 
> --
> Alex Bligh
> 
> 
> 
> 



> ------------------------------------------------------------------------------
> Find and fix application performance issues faster with Applications Manager
> Applications Manager provides deep performance insights into multiple tiers of
> your business applications. It resolves application problems quickly and
> reduces your MTTR. Get your free trial! http://pubads.g.doubleclick.net/
> gampad/clk?id=1444514301&iu=/ca-pub-7940484522588532

> _______________________________________________
> Nbd-general mailing list
> Nbd-general@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/nbd-general


-- 
< 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