You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
This repository has been archived by the owner on Jan 15, 2019. It is now read-only.
Created by mfriedrich on 2010-11-05 11:45:10 +00:00
Assignee: (none)
Status: Rejected (closed on 2011-03-18 17:28:24 +00:00)
Target Version: (none)
Last Update: 2011-03-18 17:28:24 +00:00 (in Redmine)
#770 creates the need of an neb api change. since we are bound to stay compatible, we'll have to keep that "as is" as Nagios won't change its NEB API version soon.
in order to submit our own changes and enhancements, it is required to announce an IEB and putting IDOUtils on top of that.
this will require duplicate functionality, but using a flexible modular architecture in the background, this will be the first step into a core api or somewhat similar.
idomod will register seperated callbacks and getting e.g. the expiry_time attribute from acknowledgements, handling that directly.
furthermore, the callbacks are required to put their stuff into a (message) queue, and return immediately, not blocking the core. this functionality can be easily done using a newly introduced IEB instead of an old grown, mandatory NEB.
on the testing part, a simple IDOMOD replacement should be created, working hand in hand with IEB, creating smaller and more modular code. also opening up different sockets - one for configs, one for historical data, and one for status data.
listeners like a refreshed ido2db can take on this then too, having 3 forked clients available handling 3 different types of information. a command socket would be good either way, allowing bi-directional communication.
but that's future outlook, at fist, an IEB is needed in that particular case.
The text was updated successfully, but these errors were encountered:
This issue has been migrated from Redmine: https://dev.icinga.com/issues/964
Created by mfriedrich on 2010-11-05 11:45:10 +00:00
Assignee: (none)
Status: Rejected (closed on 2011-03-18 17:28:24 +00:00)
Target Version: (none)
Last Update: 2011-03-18 17:28:24 +00:00 (in Redmine)
in order to submit our own changes and enhancements, it is required to announce an IEB and putting IDOUtils on top of that.
this will require duplicate functionality, but using a flexible modular architecture in the background, this will be the first step into a core api or somewhat similar.
idomod will register seperated callbacks and getting e.g. the expiry_time attribute from acknowledgements, handling that directly.
furthermore, the callbacks are required to put their stuff into a (message) queue, and return immediately, not blocking the core. this functionality can be easily done using a newly introduced IEB instead of an old grown, mandatory NEB.
on the testing part, a simple IDOMOD replacement should be created, working hand in hand with IEB, creating smaller and more modular code. also opening up different sockets - one for configs, one for historical data, and one for status data.
listeners like a refreshed ido2db can take on this then too, having 3 forked clients available handling 3 different types of information. a command socket would be good either way, allowing bi-directional communication.
but that's future outlook, at fist, an IEB is needed in that particular case.
The text was updated successfully, but these errors were encountered: