summaryrefslogtreecommitdiffstats
path: root/common/elapi/elapi_internal.c
Commit message (Collapse)AuthorAgeFilesLines
* COMMON Fixes to return values, errno, leaksDmitri Pal2009-08-201-3/+3
| | | | | | | | | | | | | | | | | | | | Started looking at the ticket #107 related to traverse functions. Realized that the return values are not consistent. That ovelapped with the work that I wanted to do for ticket #103 - errno cleanup. So I (across collection, INI and ELAPI): * Made the return codes consistent (where found) * Removed errno where it is not needed While was testing used valgrind and found a nasty problem when the value was added to collection with overwriting duplicates the count was decreased improperly. Fixing collection.c to not decrease count made valgrind happy. While I was debugging this I also spotted several build warnings in trace statements when the " exp ? v1 : v2 " was used. Fixed those. In ini_config.c there was a trace stament that used variable after it was freed. Removed trace stament.
* ELAPI: Adding concept of targetsDmitri Pal2009-08-201-67/+446
| | | | | | | | | | | | | | | | | | | | | | | | | 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
* ELAPI Next round of functionality - logging part of the interfaceDmitri Pal2009-08-121-0/+231
a) Added the main logging interface which allows creating dispatcher and logging messages or events. Can't actully log anything yet since the sinks are stubbed out. b) Made default template be a part of the default dispatcher. c) Updated UNIT test. d) Some of the calls are stubbed out but they are there to indicate where next round of work will be.