[SSSD] Design proposal about INI interface improvements

Dmitri Pal dpal at redhat.com
Wed Mar 24 23:46:04 UTC 2010


Hi,

Currently the INI interface includes the following functions:

int config_from_file (const char *application, const char *config_filename,
                      struct collection_item **ini_config, int error_level,
                      struct collection_item **error_list)

    Read configuration information from a file.

int config_from_fd (const char *application, int fd,
                    const char *config_source,
                    struct collection_item **ini_config,
                    int error_level,
                    struct collection_item **error_list)

    Read configuration information from a file descriptor.

int config_from_file_with_lines (const char *application,
                                 const char *config_filename,
                                 struct collection_item **ini_config,
                                 int error_level,
                                 struct collection_item **error_list,
                                 struct collection_item **lines)

    Read configuration information from a file with extra collection of
    line numbers.

int  config_from_fd_with_lines (const char *application,
                                int fd,
                                const char *config_source,
                                struct collection_item **ini_config,
                                int error_level,
                                struct collection_item **error_list,
                                struct collection_item **lines)

    Read configuration information from a file descriptor with extra
    collection of line numbers.

int  config_for_app (const char *application,
                     const char *config_file,
                     const char *config_dir,
                     struct collection_item **ini_config,
                     int error_level,
                     struct collection_item **error_set)

    Read default configuration file and then overwrite it with a specific
    one from the directory.


First two and the last one are high level functions.
The other too (with_lines) are experimental next level functions exposed
for future use and documented as such.
I suggest that we eliminate these two functions and add the following:

int config_from_file_with_metadata (const char *application,
                                    const char *config_filename,
                                    struct collection_item **ini_config,
                                    int error_level,
                                    struct collection_item **error_list,
                                    uint32_t metaflags,
                                    struct collection_item **metadata)

    Read configuration information from a file with meta data about the
file.

Similarly replace config_from_fd_with_lines with 
config_from_fd_with_metadata and
add config_for_app_with_metadata.

 The exiting functions would just be wrappers around those with
metaflags = 0 and metadata arguments equal to NULL.

The metaflags would actually control what additional information to get
for example application might want to know who is the owner of the INI
file,
what the permissions are, when the file was created or last modified.
It can also ask to record the error (if any) that happened during the file
open operation. It can also ask to return the collection of line numbers -
this is for future grammar validation.
The matadata object, though a collection under hood, will have a similar
interface as the rest of the INI interface. I mean one would be able to
do the searches for the elements of the metadata by name, free the object
after use, etc.

Introducing the metadata concept paves a way to solving several tickets
that are currently in the backlog:
https://fedorahosted.org/sssd/ticket/405
https://fedorahosted.org/sssd/ticket/173
https://fedorahosted.org/sssd/ticket/82 - for it the application can
inspect metadata before trusting the configuration data it read and
proceeding.
It also makes the interface more extensible for special cases and
special data that might be needed in future for grammar validation
or for security chacks of for other cases like detecting if
the configuration has changed since the last time the application
read it.


Any objections if I do this when I have a spare moment?


-- 
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