Dmitri Pal wrote: > 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. > > Steven suggested b) and this is what I implemented.
-- 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
