Pierangelo Masarati wrote:
hyc@symas.com wrote:
Seems that we should add a backend_attribute handler to the translucent overlay.
That's not going to work anyway, since the overlay's bi_acl_attribute method is not going to be called anyway. In fact, any call to backend_attribute will be cast into a call to bi_entry_get_rw, so only by implementing translucent_entry_get_rw we could have a chance to look the remote entry up. But then we'd probably have issues in the subsequent call to translucent_entry_release, to distinguish whether the looked-up entry was from the local or the remote database... And see ITS#5650: right now, even if the attribute is not local, the local entry will always be returned.
I think in most cases the entry that translucent returns will have to be constructed from both local and remote anyway. In which case, translucent_release should just be a call to entry_free; the original local entry should be duplicated and released immediately.
I've also tried to hack the translucent overlay so that it would support the bi_entry_get_rw callback but I haven't been able to provide something that would even satisfy me. I suppose I would have to use some sort of callback mechanism like translucent_search_cb but I haven't figured it out yet.
That's another problem I ran through when trying to add rewrite capabilities to the slapo-rwm(5) overlay, so that authorization could be rewrapped when performed through virtual data views. However, I believe the API of bi_entry_get_rw be modified for overlays, since the current API does not allow calls to modify their arguments. I'd leave that alone by now.
Haven't looked closely at this yet...