On Sat, Oct 15, 2016 at 07:45:48AM -0700, Lars Schneider wrote: > >> I have to agree that "capability=<capability>" might read a > >> little bit nicer. However, Peff suggested "<capability>=true" > >> as his preference and this is absolutely OK with me. > > > > From what I remember it was Peff stating that he thinks "<foo>=true" > > is easier for parsing (it is, but we still need to support the harder > > way parsing anyway), and offered that "<foo>" is good enough (if less > > consistent). I don't mind that much if you want to do it the other way. You are the one writing the parsing/use code. > > Also, with "capability=<foo>" we can be more self descriptive, > > for example "supported-command=<foo>"; though "capability" is good > > enough for me. > > > > For example > > > > packet: git> wants=clean > > packet: git> wants=smudge > > packet: git> wants=size > > packet: git> 0000 > > packet: git< supports=clean > > packet: git< supports=smudge > > packet: git< 0000 > > > > Though coming up with good names is hard; and as I said "capability" > > is good enough; OTOH with "smudge=true" etc. we don't need to come > > up with good name at all... though I wonder if it is a good thing `\_o,_/ > > How about this (I borrowed these terms from contract negotiation)? > > packet: git> offers=clean > packet: git> offers=smudge > packet: git> offers=size > packet: git> 0000 > packet: git< accepts=clean > packet: git< accepts=smudge > packet: git< 0000 > > @Peff: Would that be OK for you? Is it always an offers/accepts relationship? Can the response say "you did not ask about <foo>, but just so you know I support it"? I cannot think offhand of an example, but at the same time, if you leave the terms as generic as possible, you do not end up later with words that do not make sense. It is trading off one problem now (vagueness of the protocol terms) for a potential one later (words that have a specific meaning, but one that is not accurate). I don't have a strong preference, though. -Peff