[SSSD] Design proposal about INI interface improvements

Dmitri Pal dpal at redhat.com
Fri Mar 26 15:23:23 UTC 2010


Stephen Gallagher wrote:
> 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.

I am not sure we are on the same page.
Is Simo talking about the new interfaces that I propose or the functions
that are already there that I want to remove?
Those that I want to remove are currently exposed but documented as
EXPERIMENTAL in the header file and thus in the docs.

The beauty of of the meta data approach is that I can create the
functions as I proposed and stub them out internally meaning that for
any attempt to find something in the meta data collection it will return
not found.
I see several significant values:
1) Allows me to remove currently exposed functions that I do not like
(though they are marked experimental, I am still not easy about them)
2) Creates a new interface that would be "standardized" for the meta
data retrieval
3) Allows to actually build up meta data functionality later on as
needed basis without changing the interface.

Seems like a win-win-win. And I do not see how Simo's suggestion the
applies. The old interfaces are just removed and I do not see a reason
to mark new interfaces as experimental since they will be the ones we
agree to here.

Steve I have not seen your comment about my approach to meta data
structure and helpers.
Do you agree with the approach?


>
>
> > _______________________________________________
> > sssd-devel mailing list
> > sssd-devel at lists.fedorahosted.org
> > https://fedorahosted.org/mailman/listinfo/sssd-devel
>
>
>
_______________________________________________
sssd-devel mailing list
sssd-devel at lists.fedorahosted.org
https://fedorahosted.org/mailman/listinfo/sssd-devel

-- 
Thank you,
Dmitri Pal

Engineering Manager IPA project,
Red Hat Inc.


-------------------------------
Looking to carve out IT costs?
www.redhat.com/carveoutcosts/




More information about the sssd-devel mailing list