lbd modules and recursion
abartlet at samba.org
Tue Dec 27 10:44:12 GMT 2005
On Tue, 2005-12-27 at 11:18 +0100, Simo Sorce wrote:
> On Tue, 2005-12-27 at 20:46 +1100, Andrew Bartlett wrote:
> > On Tue, 2005-12-27 at 10:33 +0100, Simo Sorce wrote:
> > > On Tue, 2005-12-27 at 20:06 +1100, Andrew Bartlett wrote:
> > >
> > > > I'm very worried that in the real world, with potentially arbitrary
> > > > modules, that such loops would be unavoidable, if modules were to call
> > > > back up the stack.
> > >
> > > Only if modules programmers do not make a rule of preventing them.
> > Or the infrastructure it setup to be less painful.
> Less painful and less functional ?
> Yes we need to search for a compromise, but let's try to see all
> > You make a big point of the schema violation prevention. However you
> > miss my point. If a module can do 'bad things' attached to the original
> > request, which clearly must go to ldb_next_request(), what do you gain
> > by saying it cannot issue new requests at that layer?
> That said module, at least, do not break the tree.
> > My point is that a module should have a consistant world view. It is
> > making modifications to what it can see of the database below it.
> > Therefore, all searches/modifications/deletes should be in reference to
> > what it can see below it. What an application may see form above is
> > irrelevant.
> It depends on what is "consistent", the primary goal is to achieve some
> operation, bu the main restriction is that the tree must remain
> consistent to the outside world. The only consistent view that matters
> is the view seen at the API level.
> Modules generally are so specialized that they care only of a little
> portion of the tree or only of some aspects of the tree, not the whole.
I expect to see more, not less development in this area, particularly as
we move to back onto arbitrary LDAP servers. As such, I worry that we
need to make it easier, not harder, to code such modules.
> > > you should use a token system of some sort inside your modules
> > > private_data to avoid recursions, but from what you say your
> > > modification will not catch your code as you are not touching
> > > userPassword yourself, so that's not a problem, the second call will
> > > pass through your module and recursion is avoided.
> > I think this is creating more work, and I don't see the gain.
> > I think it is quite sane to have modules which depend on other modules.
> > I also expect we will consolidate many of these modules.
> I agree, we will probably consolidate some of the modules in the dsdb
> tree, but this does not mean we must make up an interface that force us
> to consolidate module to keep consistency.
I still see only inconsistency in the current explanation.
> > > You MUST be prepared to handle recursion because the module you call
> > > with ldb_next_request() may call a new ldb_modify() operation.
> > I think this is the part that is creating problems. If you remove this
> > MUST (which does not currently exist in real code), I think we have a
> > simpler system.
> It does exist, there already are modules that make ldb calls inside
> themselves and when they have been made I tried to keep them logically
> safe, if they are not then work should be done o make them safer.
I've looked, and I think I see a difference. The existing cases are
looking for 'external' objects, which could for most purposed be in a
separate database, because they are otherwise unrelated.
> > > It may not be a direct call it can be any sequence of calls.
> > Indeed!
> but i is unlikely that such rare events will cause loops, we do not
> introduce modules without thinking about interactions after all.
This just feels like it is asking for trouble.
> > > As a general rule calling the stack from the start is the right thing.
> > > In some special case we may consider about breaking this rule, but I do
> > > not see as this being the case to do so, please provide more details if
> > > you think your case cannot be solved taking in account new operations
> > > are made from start each time.
> > I feel very strongly that a module should not have more than one 'view'
> > of the database. Each database should see the world as presented by
> > those modules below it. Anything more is going to simply cause
> > confusion.
> Yes, and I think the view should be the view seen at the API level, not
> some partial view seen down the path. This way all modules assumes the
> same view.
But they do not. See, this is what I find to be the problem:
A module half-way down the stack could add a new attribute to a record,
but not find it in a search done on the next line, because that search
sees things from the API, while the module just operated at it's
position in the stack.
Andrew Bartlett http://samba.org/~abartlet/
Authentication Developer, Samba Team http://samba.org
Student Network Administrator, Hawker College http://hawkerc.net
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 189 bytes
Desc: This is a digitally signed message part
Url : http://lists.samba.org/archive/samba-technical/attachments/20051227/5899c885/attachment.bin
More information about the samba-technical