ding-libs.git/elapi/elapi_test/elapi_ut.conf, branch split Unnamed repository; edit this file to name it for gitweb. Remove ELAPI from the SSSD repository 2010-02-12T13:44:11+00:00 Stephen Gallagher sgallagh@redhat.com 2010-02-09T21:02:10+00:00 c170439337e796f9d565f8a60095889d7636a310 ELAPI now lives in its own project at https://fedorahosted.org/ELAPI 
ELAPI now lives in its own project at
https://fedorahosted.org/ELAPI
ELAPI Laying foundation for the async processing 2009-09-08T23:26:42+00:00 Dmitri Pal dpal@redhat.com 2009-09-03T23:13:43+00:00 2e29828454a8566d4b0fd6ebc82746d576bfecfe A relatively small patch aligning headers and a small portion of code for upcoming implementation of the async event processing. Cleanup of the test config file. 
A relatively small patch aligning headers
and a small portion of code for upcoming
implementation of the async event processing.
Cleanup of the test config file.
ELAPI Adding file provider and CSV format 2009-09-08T23:26:27+00:00 Dmitri Pal dpal@redhat.com 2009-09-02T23:41:06+00:00 c1659a8f0537eaf873d5eb468b2bcd7392af897d This patch creates the infrastructure for logging of the event from the top of the interface to the bottom. It is a start. A lot of functionality is left aside. The attempt of this patch is pass event from caller of the ELAPI interface via targets to sinks then to providers and do serialization creating entity that is ready to be written to a file. It also implements more specific provider related configuration parameters. Also it addresses couple suggestions that were brought up against previous patch. ELAPI Correcting issues This patch addresses the issues found during the review of the previous patches and addresses ticket #166. 
This patch creates the infrastructure for
logging of the event from the top of the interface
to the bottom. It is a start. A lot of functionality
is left aside.
The attempt of this patch is pass event from caller
of the ELAPI interface via targets to sinks
then to providers and do serialization creating
entity that is ready to be written to a file.
It also implements more specific provider related
configuration parameters.
Also it addresses couple suggestions that were
brought up against previous patch.

ELAPI Correcting issues

This patch addresses the issues found during the
review of the previous patches and addresses
ticket #166.
ELAPI sinks and providers 2009-09-08T23:25:16+00:00 Dmitri Pal dpal@redhat.com 2009-08-25T20:54:01+00:00 503da84209bd42f0487f431a5aaf527828de028e This patch drills down to the next level of ELAPI functionality. I adds the creation and loading of the sinks. It also implements a skeleton for the first low level provider which will be capable of writing to a file. The configuration ini file is extended to define new configuration parameters and their meanings. 
This patch drills down to the next level of ELAPI functionality.
I adds the creation and loading of the sinks. It also
implements a skeleton for the first low level provider
which will be capable of writing to a file.
The configuration ini file is extended to define
new configuration parameters and their meanings.
ELAPI: Adding concept of targets 2009-08-20T19:47:34+00:00 Dmitri Pal dpal@redhat.com 2009-08-14T19:05:12+00:00 1a0231e8d9162a5fe568436f9db0248ddf691e63 The targets are the destinations which caller wants to send the events to. The sinks are now on the second level under targets and constitute a so called fail over chain for a target. Such approach eliminates the need for complex routing function. The dispatcher keeps the list of targets in a collection. The element in the collection is the target context. Also gispatcher keeps the list of the sinks in a separate collection. Each target context has a list of the sinks associated with this target. But those are just pointers (at least for now) to the sinks form the list kept by dispatcher. I had to add some internal debug callbacks to be able to see that all the internals of the dispatcher are actually in order. See the conttent of config file for more comments. Also see information posted on SSSD wiki. https://fedorahosted.org/sssd/wiki/WikiPage/ELAPIInterface 
The targets are the destinations which
caller wants to send the events to.
The sinks are now on the second level
under targets and constitute a so called
fail over chain for a target.
Such approach eliminates the need for complex
routing function.
The dispatcher keeps the list of targets in a collection.
The element in the collection is the target context.
Also gispatcher keeps the list of the sinks
in a separate collection.
Each target context has a list of the sinks
associated with this target. But those are just
pointers (at least for now) to the sinks
form the list kept by dispatcher.

I had to add some internal debug callbacks
to be able to see that all the internals of
the dispatcher are actually in order.
See the conttent of config file for more comments.
Also see information posted on SSSD wiki.
https://fedorahosted.org/sssd/wiki/WikiPage/ELAPIInterface