Pierangelo Masarati wrote:
What back-monitor does in many cases is monitoring entities living inside slapd. In those cases, the living entity and back-monitor's entry should be in touch with each other to account for reciprocal updating. The flow of information, so far, has been handled in one direction by providing a neutral interface (actually, two):
- the per-subsystem hooks
- the callbacks
Callbacks are much more general than per-subsystem hooks. I think per-subsystem stuff should be eliminated, as they basically duplicate callbacks with less flexibility.
However, I believe bi-directional communication could make many things much easier.
Let's think what operations may require either direction: back-monitor needs to be able to ask living entries information when it is asked to present entries (e.g. in response to a search). For this purpose, the current callback mechanism should be sufficient.
However, living entities may need to contact back-monitor for many purposes: to register new callbacks, to add/remove themselves to/from back-monitor. For this latter purpose, a solution could be to augment all living entities with a pointer to their entry in back-monitor. This pointer should be set by back-monitor as soon as that entry is created. This would ease feature registration by acting as a key (the caller would finally know the real DN of its entry), rather than figuring out a mechanism to locate it as it is currently done by the monitor_back_register_* calls. Basically, BackendInfo, BackendDB, overlay_info and overlay_inst would need an (Entry * (*)_monitor) to their entry in back-monitor, to be mostly used as a key when calling monitor-related functions. Other structures in the future may need it, but the interface would be general enough to allow extensions. Comments?
I'm not sure we need an extra Backend field for this. The same concept applies to back-config. I figure an entry point in the monitor backend bi_extra to return the pointer may be sufficient. But I guess this could go either way.