-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
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')
>
>> [snip]
>>
>> This example is completely unparseable to my brain. Could you please try
>> representing it with a real-world example, such as ldap_uri? Also, I
>> don't like seclist, secprefixref and secref. They are not descriptive
>> and it will be impossible for anyone to keep them straight.
>
> But this is what we have in sssd.conf
>
> I am talking about the:
>
> services = nss, pam
>
> Services attribute is a section list meaning that the nss and pam
> sections need to be defined.
> Another example of the section list is the "domains" attribute.
>
> domains = redhat.com
>
> But the sections are actually named:
>
> [domain/redhat.com]
> ...
>
> So to describe it one would say:
> [domais_def]
> name = domains
> section = sssd
> seclist = yes
> secprefix = domain
>
> Now imagine that "domain" is actually not a constant but a value of
> another key in the ini file.
> Then we would have to use some kind of the reference.
> That would be something like "secprefref". But currently it is not used
> so we can skip it for now.
>
> So based on the definition of the "domains" key the sections that should
> be present in the INI file
> should be constructed as the value of the key in the actual ini file
> prepaneded with the word
> "domain". So how I can say that a key should belong to such a
> dynamically defined section?
> This is where the "secref" is going to be used. See example at the end
> of the mail.
>
>
> We will need to come up with some better "implication" rules and
> describe it.
> For example: if vtype is defined it should be implied that this is a
> field. If the regex is defined then it should imply vtype = string and
> so on.
> But this we can do and build as we go.
> One lesson for this is to write good doc as you go.
>
>
>> [snip]
>>
>> See above, but we need to add, at a minimum, support for
>> regular-expression handling. I'd also prefer it strongly if we could add
>> support for something like +=
>>
>> In other words, I want to be able to say:
>> [id_provider]
>> type = field
>> vtype = multi
>> choices = local
>>
>> in the core config file, but then be able to say:
>>
>> [id_provider]
>> type = extend #implies vtype=multi
>> choices = ldap
>>
>
> I do not understand what you are trying to say here.
> I think I missed one other key that I wanted to include: values (or may
> be "choices" as you suggested)
>
> choices = local, ldap
>
> would mean that the value for the key can be only one from the list.
> If the list = yes for such value, it would mean that each of the
> values for the key in the real ini file should be one of those.
> For example:
> is schema:
>
> [family]
> name = family
> section = building
> list = yes
> vtype = string
> choices = Dad, Mom, Son, Daughter
>
> In the config file:
> family = Mom, Son, Son <- will be Ok
>
> family = Mom, Sister, Son <- will will generate and error because
> "Sister" is not a valid value
>
I think you missed my point. I was talking about the case where you want
to have a limited set of choices for an option, but you want the set of
choices to be extensible by a secondary schema file. For example, I want
to have sssd.schema to handle all the options that are available for the
SSSD itself, and then I want to have a directory (sssd.schema.d)
containing files like sssd-local.schema, sssd-ldap.schema.
In sssd.schema, I'd have:
[id_provider]
type = field
vtype = multi
choices =
In sssd.schema.d/sssd-local.schema, I'd have:
[id_provider]
type = extend
choices = local
In sssd.schema.d/sssd-ldap.schema, I'd have:
[id_provider]
type = extend
choices = ldap
Then, in sssd.conf I would be able to provide:
[domain/mydomain]
id_provider = ldap
But if I provided:
[domain/mydomain]
id_provider = nosuchprovider
I should get a parse error because that's not one of the acceptable choices.
>
>
>> in the sssd-ldap.conf and have the resulting combined INI be effectively:
>>
>> [id_provider]
>> type = field
>> vtype = multi
>> choices = local,ldap
>>
>>
>> This way, for things like the providers, we can provide a selection list
>> of options. Since otherwise, our only option would be
>> [id_provider]
>> type = field
>> vtype = string
>> regex = .*
>>
>
> So I think what you are trying to say is:
>
> (in schema)
>
> [domais_def]
> name = domains
> section = sssd
> seclist = yes
> secprefix = domain
>
> [id_provider]
> name = provider
> secref = domains_def
> vtype = string
> list = yes
> choices = local, ldap
Hopefully I made myself clear above, but just in case: 'list = yes' here
would be wrong. I don't want id_provider to accept a list of values, I
want it to have a single value chosen from a list that may have been
constructed and extended from multiple different files.
>
> (will mean that)
>
> The key "provider" will have a string value from the provided
> choice of "local, ldap" and will belong to the section that will be
> dynamically
> constructed from the value of the key "domains" in section "sssd" using
> prefix "domains"
>
> [sssd]
> domains = somewhere.com
> ...
>
> [domain/somewhere.com]
> provider = ldap
> ...
>
>
>
>
- --
Stephen Gallagher
RHCE 804006346421761
Delivering value year after year.
Red Hat ranks #1 in value among software vendors.
http://www.redhat.com/promo/vendor/
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/
iEYEARECAAYFAku820AACgkQeiVVYja6o6PHGQCffEKj8l2fESFH4Gi6nWUDX3lN
f/sAnilt5xIZThywFbZ/VzeCzK5fFtcd
=LnBy
-----END PGP SIGNATURE-----
_______________________________________________
sssd-devel mailing list
sssd-devel@lists.fedorahosted.org
https://fedorahosted.org/mailman/listinfo/sssd-devel
