[Fedora-directory-users] Virtual DIT views vs hierarchical DIT

[Pete Rowley]

> -----Original Message-----
> From: fedora-directory-users-bounces at redhat.com 
> [mailto:fedora-directory-users-bounces at redhat.com] On Behalf 
> Of Sam Tran
> Sent: Friday, June 24, 2005 11:34 AM
> To: General discussion list for the Fedora Directory server project.
> Subject: [Fedora-directory-users] Virtual DIT views vs 
> hierarchical DIT
> 
> Hi,
> 
> I just read about the virtual DIT views in the Red Hat 
> Directory Server Deployment Guide.
> 
> I was wondering how well the virtual DIT views work compare 
> to an hierarchical DIT structure?
> 
> Generally speaking is it better to have a flat DIT and 
> virtual DIT views than an hierarchical DIT?
> 
> Any comments or experience would be much appreciated.

In general, a flat(ish) DIT means less administrative overhead - if
everything is in one place, there is nowhere to move it to etc.  The issue
with DITs is that there are competing contenders for its structure, some
dictated by applications, some by your deployment topology.  Since your
deployment topology will (and should) win (design your dit around your
replication requirements), views can be used for your other dit structure
requirements.

There are a few issues with views as they currently stand that you should
consider before deployment:

A) they currently have no internet draft or RFC, and to my knowledge no
other server impliments them - only you can tell if this matters

B) they do not work with access control - that is to say, an aci on a views
entry will not target the virtual view descendents, only entries that
actually exist in that part of the dit.  This is an obvious enhancement
waiting to happen ;)  They _do_ work with both cos and roles, so it is
possible to achieve the same functionality using role based aci's referring
to roles with views as parents - but that is a bit more ungainly than I
would like

C) they do not work across multiple backends i.e. if a view hiearchy crosses
a backend boundary, searches at the top most views will not return the
entries from the lower views.  Actually this is a bug which is a quirk of
the ordering of view search translation and backend selection, they are the
wrong way around (and if I recall correctly, should be able to be switched
without incident - the calls are even in the same function)

D) Entry DN's are not disguised, that is views does not try to make the
entry DN of the returned entries look like they physically exist in the view
hiearchy.  It is possible that this might fool some clients that do DN
manipulation - most won't care however.

Other than that, view look and work like a real DIT and since they work by
manipulating the search options they scale right along with directory
searches.  Setting up indexes for attributes used in views filters will
certainly speed those searches too.