On Wed, Apr 7, 2010 at 1:02 PM, Dmitri Pal <dpal(a)redhat.com> wrote:
Stephen Gallagher wrote:
> On 04/07/2010 02:46 PM, Dmitri Pal wrote:
> > See below
> >> We really need to have
> >> regex =
> >> as an option. For example:
> >> [ldap_uri]
> >> type = field
> >> vtype = string
> >> regex = ldaps?://[\w\.]*
> >> list = true
> >> sep = , #How would we do space-separation? Should we even bother?
> >>
> > We can look into regex validation. Do not see big deal here.
> > Will be a special function though. Can be added incrementally
> > in a separate patch and handled as a separate task
> > (within v1 validation functionality).
>
> > As for separators I imply that space is always a valid separator.
> > Those would be additional separators we can check.
>
> I think it makes sense to NEVER use space as a separator, so that the
> use of a separator then becomes explicit and unambiguous. (And it's
> possible to add human-readable spaces around a separator)
>
> > Adding comma to the list for example would not generate an error and
> > would parse list:
> > foo bar baz
> > the same way as
> > foo,bar,baz
> > or
> > foo, bar, baz
>
> > There was a bug recently about the similar issue.
> > Multiple separators for a list is already baked into the parsing logic.
>
>
> My concern is for the possibility of options where you specify
> foo bar, baz
>
> Because with your proposal, this is always translated to:
> (foo, bar, baz), when what they really wanted was (foo bar, baz)
>
> Right now in the SSSD there aren't any cases like this, but we're trying
> to build libini_config for general consumption. I don't think we're out
> of line requiring an explicit separator. Additionally, we can add
> another rule that whitespace surrounding a separator is not included in
> the value.
>
> So name = value1\s\s\s,\svalue2 would become ('value1', 'value2')
and
> not ('value1 ', ' value2')
>
I kind of disagree with the whole approach.
If you want spaces inside the value you need to make the string quoted.
Something like
value = "fist value", "second value"
JSON != ini. As a format, ini allows spaces just like Stephen posted.
If you want something like JSON perhaps the config format should
indeed be JSON or YAML. However, I think Stephen is correct in that:
key = value1, value two, valueTHREE
should evaluate to this in python syntax:
key = ("value1", "value two", "valueTHREE")
What you proposed seems counter-intuitive.
This is currently not supported but would be easy to add when
needed.
But again we are talking about the ini files and explicitly multi value
lists.
It is not a good practice to have spaces in the multi value lists anyways.
And I do not want people to encourage doing it.
In case of single value the inner spaces are preserved but leading
and trailing ones are trimmed.
Explicit is always better than implicit. The reverse is poor design in
most cases. Take a look at places where this caused problems in the
past *I'm looking at you php's magic quotes*.
--
Jeff Schroeder
Don't drink and derive, alcohol and analysis don't mix.
http://www.digitalprognosis.com