-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On 03/26/2010 10:25 AM, Dmitri Pal wrote:
Stephen Gallagher wrote:
> On 03/26/2010 05:31 AM, Jakub Hrozek wrote:
>> On 03/25/2010 11:12 PM, Dmitri Pal wrote:
>>>> Any objections if I do this when I have a spare moment?
>> ^^^^^
>
>>>>>
>>>>>
>>> Does anybody care?
>
>> My bet is that there were no objections so the silence meant "go
> ahead" :-)
>
> Well, I'd actually like to make some comments. I was just too busy
> yesterday to get to review this.
>
> I like this approach to a point. Having a collection-driven metadata
> mechanism that can handle arbitrary controls for the ini file is a great
> idea. I'm struggling a bit to understand how exactly you would generate
> the metadata collection. I think we need to discuss ahead of time what
> the interfaces to helper functions would look like.
>
> I can guarantee you that no one is going to want to use the low-level
> collection API to write this metadata.
>
> Before you start implementing this, please propose a helper API as well.
>
My thought was that the metadata collection would have the same
structure as INI file collection.
It will have some predefined sections and keys under these sections like:
[Access]
owner = <ini file owner>
group = <ini file group>
permissions = <permissions word>
read_error = <file open error if any>
...
[Stats]
name = <file name>
created = <time stamp>
modified = <time stamp>
...
etc.
So for this layout one would use same functions that one would use to
get values from INI file collection, i.e.
get_config_item and then interpret it with conversion functions.
Since some of the values might be more complex than the basic values we
currently handle special helper conversion functions would be added to
handle these cases on per type of data basis.
For example the collection of lines for the error reporting when the ini
file is checked for correctness can be retrieved as an item but then
handed with special functions.
Since I do not have enough vision about it at the moment I want to defer
making any decision about it and special functions that will be needed now.
The meta data approach allows me to hide this collection and leave it
till the time when it is actually needed.
As for Simo's comment, I would prefer removing the mentioned functions
and replacing the with the meta data ones in one step.
This is why I started this discussion.
I don't think that's in conflict. I think he means that the new
interfaces you add should be marked with an unstable ifdef until we know
they're complete and ready to be used.
_______________________________________________
sssd-devel mailing list
sssd-devel(a)lists.fedorahosted.org
https://fedorahosted.org/mailman/listinfo/sssd-devel
- --
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/
iEYEARECAAYFAkusxpIACgkQeiVVYja6o6M78wCdEinEuszKg+xtsA2K7e2lxvpD
9ksAmwT070hfOkzYEwR7bT+sVbpKxn7V
=deYR
-----END PGP SIGNATURE-----