Hello Willy, On Mon, Mar 5, 2018 at 8:37 PM, Willy Tarreau <w...@1wt.eu> wrote: > Quotes could be part of some future statements and we'd > possibly regret having used them if already used for this. For example we > could > imagine one day uploading some JSON parts for certain things.
True, but it could also be addressed by switching the input mode to a certain flavour (JSON, XML, whatever) but it is also true that handling multiple lines also solves the problem and does not require supporting quotes. > Probably that we could in fact extend the CLI syntax in a backwards compatible > way : > > <word>[ <word>]* <arguments>* > [optional body] > > Most commands don't use a body. Those using a body have to terminate it using > either its own representation known by the command, or an empty line. Wouldn't it be easier/clearer to always require an empty line if there is a body ? Even if it can be present but optional, an empty line would still signal the end of it. > "set ssl ocsp-response" takes a series of words in arguments, or a body. > Some commands might even simply support the concatenation of both, ie they > start immediately on the argument, detect the block is not completed, and > read the rest on the following lines till the end is found (either defined > by the data format or by the empty line). This simplifies the syntax of > long commands, to support both the first line as the first series of > arguments, or as the first line of the body. Basically, it boils down to adding multi-lines support to the CLI, right ? The parser will have to be modified to wait until a keyword handler says it is ready to process the command if it has every argument it needs (continue) or some are missing (fail). > > E.g. we could write (just using maps as a simple example) : > > add map foo.txt foo1 bar1 > > or: > > add map foo.txt > foo1 bar1 > foo2 bar2 > LF [1] > > For OCSP, we could have : > > set ssl ocsp-response line1 > line2 > line3 > line4=== > > or : > set ssl ocsp-response line1 line2 line3 line4=== > > or : > set ssl ocsp-response > line1 > line2 > line3 > line4=== Is there an advantage to allow these two syntaxes versus always the one in [1] ? Why not always requiring an empty line if multi-line is used ? That would still require cooperation from the handlers but it will stay simple: do I have enough data to proceed ? In the case of ocsp-response, without an empty line, it would mean trying to decode the whole buffer at each new data - or maybe just what was added if base64dec() is modified to support partial data. Waiting for an empty line would simplify the logic by only decoding the buffer once - this is an example for ocsp-response but I think processing arguments once is easier than processing them at each new data. Requiring an empty line would also solve the case of commands with an unknown number of arguments. I do not know if there are some yet but they could then safely be added. In the particular case of a PEM certificate, the handler would wait for an empty line and it would know it can treat what is after the known arguments as being the certificate without trying to guess it is complete - in the case where there would be no empty line. Thanks ! -- Aurélien Nephtali
