Dmitri Pal wrote:
> 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?
>
>
>
Does anybody care?
I don't really have objections.
But it would be nice if you could mark unstable interfaces so that
people understand not to rely on them until they are marked stable.
Something like:
#ifdef _ENABLE_LIBINI_EXPERIMENTAL_
... declarations ...
#endif
Simo.
--
Simo Sorce * Red Hat, Inc * New York