Re: [SSSD] Looking for a bit of advice
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/