Dmitri Pal wrote: > Hi, > > I am working on the next set of changes for ELAPI and have a question. > With some recent changes to the design the terminology looks like this: > target - a destination where the event is sent. Target consists of chain > of sinks in priority (fail over) order. So if one sink fails next sink > in the chain will be used. > Imagine now two sinks in the chain. The first sink is to write to the > file on the NFS and the second to write to the local file. They differ > in configuration but the code is the same for both sinks. > This brings to the notion of "provider". Provider is the implementation > (the code) to write to specific destination that can be configured in > different ways. The sink then a provider + configuration. > Also some of this can be read here: > https://fedorahosted.org/sssd/wiki/WikiPage/ELAPIInterface > > Ok so not when we are clear (hopefully) on the terminology let me ask > the question. > Under directory that contains mail ELAPI code (which is > sssd/common/elapi) I plan to have sub directory named "providers". Under > it there will be directory for "file" provider, "syslog" provider, > "stderr" provider and other providers. Generally the providers should be > implemented as shared libraries and that will be the case. However per > Simo's suggestion I plan to embed the three basic providers: "file", > "syslog", "stderr" into the ELAPI library itself. This means that these > providers have to be built before I build the rest of ELAPI library and > its unit tests. Other (loadable) providers do not cause any dependency > on the core ELAPI code and can be built separately. So how should I > better organize the tree and build process. > I can: > a) Since the loadable libraries can be built independently they probably > should live in other part of the tree, right? Then does it make sense to > have the hierarchy that I plan? May I should just put all the code for > the basic providers into the elapi directory itself? > b) Another option is to keep this code structured as I plan but do not > have makefile.am and configure.ac in the subdirectories and build the > standard providers from within the elapi makefile. > c) Add makefile.am and configure.ac into the "provider" subdirectory and > individual provider directories, build independent libraries for each > provider and then use these libraries when I build elapi and its unit test. > > The first option is the simplest but then I will have a mixture of file > prefixes in one directory. The source files that constitute core of > elapi start with "elapi_" but the providers start with provider name > like "file_provider.c", "stderr_provider.c" etc. > The second one does not seem to be inline with automake guidelines as > far as I understand them. > The third one is the most complex. > > So which way should I go? > > Managed to make it build with third option. Ugly... :-\ It would be easy to convert it to either of the first two if you think it makes sense.
-- Thank you, Dmitri Pal Engineering Manager IPA project, Red Hat Inc. ------------------------------- Looking to carve out IT costs? www.redhat.com/carveoutcosts/ _______________________________________________ sssd-devel mailing list [email protected] https://fedorahosted.org/mailman/listinfo/sssd-devel
