Stephen Gallagher wrote:
On 03/26/2010 11:23 AM, Dmitri Pal wrote:
> 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.
If you remove interfaces, please remember to bump the soname. That's an
ABI break. I think you are correct that Simo's comments no longer apply
in that situation.
> Steve I have not seen your comment about my approach to meta data
> structure and helpers.
> Do you agree with the approach?
The approach seems fine to me.
Good, I will work on the patch over the weekend.
This will put my mind to rest about INI.
_______________________________________________
sssd-devel mailing list
sssd-devel(a)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/