Thread (29 messages) 29 messages, 5 authors, 2016-10-16

Re: [PATCH v10 13/14] convert: add filter.<driver>.process option

flat view

From: Jeff King <hidden>
Date: 2016-10-16 00:33:52

On Sat, Oct 15, 2016 at 07:45:48AM -0700, Lars Schneider wrote:
quoted
quoted
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.
quoted
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
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help