On Fri, Apr 06, 2018 at 03:59:59PM +0200, Aurélien Nephtali wrote:
> I tried to be the less intrusive as
> possible into the CLI parser so I tried to reuse what was already
> done.
> Maybe that's not the best approach but with all the legacy behind I
> REALLY didn't want to break something, even if it lands on a
> development branch :).

It's not a problem to heavily modify what exists as long as it ultimately
works. That always happens anyway. The problem by being too conservative
is that the code gets totally glued together and when someone wants to
rework it, he realizes it's too late, so prefers to add further crap on
top of it and this never ends, until something really breaks and we regret

Obviously, changes for changes are not always welcome and changes for a
good reason are welcome, which is the purpose of the discussions on the
list :-)

> Using a special pattern is a good idea. Let's start with "<<" and
> tweak it later if it collides with what can be found in a payload.


> > The benefit here is that it's still the parser which knows whether or
> > not a payload follows, regardless of the command, and can simply pass
> > a flag to the command saying "you have a payload to read".
> Yes, in fact that's exactly what I did at first but I really thought
> it was too ambitious and subject to compatibility-breaking (again due
> to my lack of background on the CLI/HAProxy usage).

No problem.

> I realize I wanted to be too generic to be sure I would not break
> anything but I ended doing something too light.

It's fine (and often desirable) to be generic for the long term. There's
no problem being restricted for the short term if you have some visibility
over the next steps to reach the long term. Sometimes you may also want to
do some "disposable" code. Experience taught us that such code remains
almost forever (haproxy itself started like this). But sometimes it helps
getting a first version of something. It often makes it very hard to work
around this however.

> Ok, I'll do that in a way it will be easy to enhance.

Great, thank you.

Thanks for your understanding. Do not hesitate to ping an insist when
you need some inputs that are not coming fast enough, I know it's never
fun to have to redo some work differently after reviews. Hint: don't
worry about updating the doc during design reviews ;-)


Reply via email to