defining the new idmap subsystem

[simo]

On Mon, 2006-10-02 at 20:20 -0700, Jeremy Allison wrote:
> On Mon, Oct 02, 2006 at 11:10:54PM -0400, simo wrote:
> > On Tue, 2006-10-03 at 13:03 +1000, Luke Howard wrote:
> > > >I think the code will be much uglier but if most want that, so be it.
> > > >But I'd like some more people complaining about that, before changing.
> > > 
> > > I agree with Jeremy, having something done as a side-effect of an
> > > interface whose primary purpose is to query seems like a bad idea
> > > to me.
> > 
> > The problem is that the primary purpose depends on the context.
> > In some cases we just want to know if a mapping exist, but don't want to
> > actually trigger a mapping, in others we want to trigger a new mapping,
> > but that will happen only if the backend supports it.
> 
> Then we code so that we query first, and if it fails we request
> a mapping, and deal with a failure if the backend doesn't do
> mappings.

This means practically exposing the cache to the caller, and often
duplicating calls which are not so fast as we decided to make all calls
use the winbindd async interface.
This would be uglier than the current interface.
I can agree to make the function names explicit, but I don't agree to
expose the cache and the decision on how and when to ask the backends to
the caller. That should be opaque.

The only real reason why we introduced the QUERY_ONLY flags is to avoid
DOSs by depletion of usable ids. Ideally we always want to make an
allocation if possible.

So normally NOT allocating is a sort of side effect.

> We must not add allocation as a side effect. Been there, done
> that - had to track down the bugs. Not doing it again :-).

I am not sure what you propose will make it any better.
We actually do make checks in winbindd we shouldn't and that's because
we explicitly test before. I'd like to be as transparent as possible and
let idmap decide what to do, I can't do it 100% of the time, that's why
I need that flag, but I don't like to go and put back the logic in
winbind, as it would be abused again and the policy will risk to not be
consistent again.

Simo.

-- 
Simo Sorce
Samba Team GPL Compliance Officer
email: idra at samba.org
http://samba.org