On 02/13/2013 10:40 PM, Nathan Kinder wrote:
With the DS plug-in approach that calls into the IPA framework with a
'mock add' to form the resulting entry at the pre-op stage, we could
take care of the initial ADD operation of the user entry. We would
still need to have a way to trigger the additional write operations that
the IPA framework performs. The proposed DS plug-in could do an
internal search operation after the add, then it could perform the
additional write operations that are needed. This logic would need to
be in the DS plug-in, or we would need another way to get the details
from the IPA framework via JSON. The approach begins to get a bit messy.
Messy is one word for it :-) Herein lies the problem. user-add is
actually a simple case where in this particular version of our code we
know the LDAP operations that occur and in what order. But there is
nothing in our coding guidelines that guarantees this, it just happens
to be true today. Pre and post callbacks are free to do as they please.
The logic in our ldap module can change (in fact it's undergoing a
rewrite as we speak). We've committed to supporting an extension
mechanism (plugins) that ties into the framework operations and who
knows what might occur in that code. At the moment it's not used, but
hopefully it will be.
Then comes the question, where do we draw the line? Do we say only
user-add with no additional options is supported because we know what
occurs during it's processing and hence we feel safe emulating user-add
outside the framework?
We all know this is a slippery slope, as soon as you support user-add
this way we'll be getting requests to support other commands or other
options. And after we make framework changes (which we do frequently)
are we going to test these out-of-band operations continue to emulate
the ever changing framework?
It's a slippery slope that can expose us to problems we don't need.
Jenny, do you want to test an entirely different mechanism or do you
want to limit it to our defined API?
We have a defined API, I really think that's the only thing we should
support. Backdoor shortcuts that sidestep our framework should be off
the table IMHO, it's just inviting too many problems.
--
John Dennis <jden...@redhat.com>
Looking to carve out IT costs?
www.redhat.com/carveoutcosts/
_______________________________________________
Freeipa-devel mailing list
Freeipa-devel@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-devel
