Re: [PATCH] Unknown cfg function

On 08/28/2013 06:04 PM, Alex Rousskov wrote:
> On 08/21/2013 09:34 AM, Tsantilas Christos wrote:
>> On 08/13/2013 11:57 PM, Alex Rousskov wrote:
>
>>> Another potential problem here is with the '=' character. We have to
>>> allow it because existing code expects it in directive options with
>>> values (e.g., bypass=on). However, making '=' a part of the token makes
>>> it difficult to support quoted option values:
>>>
>>> bypass="on" // illegal because a token cannot have quotes
>>>
>>> "bypass=on" // legal but looks kind of weird
>>> // because there are actually several tokens here
>>>
>>> For simple values such as "on", this is not a problem, but not all
>>> option values are that simple, and some of them will require quoting:
>>>
>>> uri="icap://example.com/?mode=reqmod" // illegal?!
>>>
>>> "uri=icap://example.com/?mode=reqmod" // weird
>>>
>>> Changing all callers to treat name=value sequence as three tokens is
>>> probably too much work, right?
>
>
>> This is requires changes in many places...
>
>
> I am afraid this problem is serious enough to warrant more discussion
> and possibly more work. It feels wrong to insist that folks do
>
> "foo=bar and baz"
>
> instead of the natural
>
> foo="bar and baz"
>
> and now may be our only chance to add proper support for that.

So we can consider the "=" as a separator char. Probably we can support
syntax like the followings:
  foo="bar and baz"
  foo= "bar and baz"
  foo = "bar and baz"

>
>
> What do others think? Is this important enough to fix?
>
>
> If we decide proper support for foo="bar and baz" syntax is important,
> the biggest question for me is whether we should
>
> * change the callers to deal with three tokens (option name, equal sign,
> and option value) or
>
> * change the parser to hide the quotes (producing a single complex token
> with "=" inside but without quotes so the callers work as is)

Looks that the first is the correct.
I am seeing many problems in the second solution. Valid tokens may
include "=", for example a url.
How we are going to interpret them?

>
> The former requires more development work but is probably the Right
> Thing to Do.
>
>
> Thank you,
>
> Alex.
>
>
Received on Wed Aug 28 2013 - 15:31:18 MDT