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 it. 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. Great. > > 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 ;-) Thanks, Willy
