directory-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Marc Boorshtein" <>
Subject Re: [ApacheDS] Specifying application level subtrees?
Date Fri, 21 Sep 2007 22:48:00 GMT
> > If the user is a member of the group then the group dn will be
> > returned as the only entry.  While there are definitely really badly
> > written applications that will retrieve the entire group and then do
> > an evaluation thats pretty rare.
> Yeah this is what I am afraid of.  I know of many apps like this
> unfortunately.  Some
> are really big commercial applications yuk!

Fair enough.

> > I've actualy deployed this
> > solution with Oracle's virtual directory where the static members were
> > 150k-500k members (and is a 256mb entry any better then a 512mb entry?
> > :-D) and it worked very well.
> Haa!  That's crazy. Try doing that under heavy load.  I'd like to see how
> the VD then handles OOM
> exceptions.

It was under VERY heavy load (I don't remember the number of users).
The application (a consumer side portal) did az checks with a search
so it wasn't pulling back the entire group.

> > I'm still not sure what the advantage of your solution is over a
> > dynamic group, but I'm probably missing something.
> Hmmm are you up to date on the X.500 admin model?  SubtreeSpecifications and
> what not?
> The whole point is to leverage the same concepts rather then the standard
> dynamic group
> being based on the LDAP URL.  SS is much more flexible.

Got me.  I know very little from X.500 beyond my experience with
eDirectory and CA eTrust Directory.  We come from different
perspectives (which is generally good).  I come from an application
integration and data systems background as opposed to an
infrastructure background.  The end of it is I care about how
something is accessed by an application and  that data is not
duplicated on the backend.  Everything in between I generally leave to
people who are much better at it then I.

> > Good luck to you there...I don't know that there will ever be an
> > LDAPv4 but I suppose thats another discussion.
> As with everything it's up to the community.  I don't know either and it's
> probably a pipe dream
> but oh what a good dream it is.

Fair enough

> > > Incidentally Authorization is already handled correctly by the X.500
> model
> > > which is being
> > > specified in LDAP with the work being done by Steven Legg here:
> > >
> > >
> > >
> > > Authorization does not need this after this draft becomes an RFC which
> shows
> > > a strong
> > > liklihood.  ApacheDS uses this same model - this is why we stuck so
> close to
> > > the X.500
> > > standards in our AC implementation.
> > >
> >
> > Well, I'm not a huge X.500 fan but you say tomatoe....I'm curios to
> > check out the spec though.  Thanks for the pointer.
> Well you're going to need to be.  I know reading X.500 specs make the best
> ambien replacement in the world but LDAP is based on X.500 and is moving
> closer to it.

As per my explanation above, I really don't care whats under the covers.

> IMO LDAP was too lightweight in an adverse reaction to the
> weight of X.500.  So now people realize we have to embrace X.500 concepts
> and in particular the admin model.  Lookie here ..

OK, so this is starting to get really philosophical but I think LDAP
is just fine.  LDAP is a directory ACCESS protocol.  How that
directory is implemented shouldn't matter.  As a matter of practice I
prefer simple to complex.  There are many good things about X.500
(which are the roots of virtual directories), but I don't think we
should confuse the access protocol and the implementation protocol.

> There's much more coming down the pike.  I've been dreaming about the day
> this would happen.  The admin model is going take the ad hoc crap out of
> implementations today.  Standards are the only way to reach true
> interoperability
> across these ideas here.

I don't follow here what you mean by 'ad hoc'?

> > Extended operations & controls are great and all but applications just
> > don't use them.  If I were to design my super group it would have 4
> > requirements:
> >
> > 1.  Members can be dynamic
> > 2.  Members can be static
> > 3.  Members can be other groups
> > 4.  I can test a group membership with a single ldap search call
> I like these items here especially #3 which did not occur to me until now.
> Also note you can use a compare
> op too but you're right most apps don't have a freakin clue about how to do
> a compare either.   The name of
> this game is to cater to the dumb clients already out there that won't
> change.
> We do have our class of problems but we'll solve them with time.  My whole
> angle with this stuff
> is to do it while extending (through IETF) and complying with standards and
> expected semantics.
> ADS is trying to achive these feature carefully without being another ad hoc
> concoction to respond
> to the market.  We want to outlast the fads.

Isn't the market the ultimate decider of such things?  How can you
build something that will outlast the 'fads' if the market wont accept
it.  Isn't Windows an unfortunate example of this?  Netware, Os/2,
BeOS..(linux?) were all considered far 'better' but the market said
windows (yes, this is simplistic and does not take into account M$'s
biz tactics but the analogy is one of a million in this industry).  We
(where we is any one person or group) do not decide what will work
best, the market will.

> In fact I am certain virtualization can have a solid theory behind it
> through the X.500 admin model.

Given the many virtual directory deployments out there I would say it
has passed 'solid theory' quite some time ago.  Yes it has its roots
in X.500 and whats old is always new again but lets not make too many
assumptions here.

> I'm in the process of defining conceptually views for LDAP using the admin
> model and stored
> procedures.  This however is future work.

Another discussion.

> > I do say I'd be very interested to get the other open source ldap
> > proejects (opends, openldap, penrose & fedorads) opinions on the
> > matter.
> >
> Hmmm as you know I've been intricately involved with the Penrose peeps
> having helped them use
> apacheds under the hood.  I withdrew from them for various reasons but one
> was because they
> don't have a clue about the protocol and X.500.  Penrose is just an ad hoc
> concoction to make money

Was that necessary?  I've worked with the Penrose folks and have a lot
of respect for them.  This is a discussion about technology and
problem solving, not a mud slinging session.  Don't put down other
projects just because you disagree with their choices.

> quick. Nothing wrong with that but it bastardizes the technology with
> one-offs jammed in to make
> it to market.  You need a balance.

And who decides that balance?  You?  The ApacheDS group?  This gets
back to the comment above about the market deciding what will last.

> The other efforts are legitimate IMO but these folks are best engaged
> through an open specification
> process.

I COMPLETELY disagree.  The standards process should be the LAST step.
 The best codified standards are first defacto standards.  By bringing
it up among different groups we gain the intelligence and smarts of
the collective, but by implementing it with our own ideas we allow the
market to decide what the 'best' way to go is.


View raw message