> -----Original Message----- > From: fedora-directory-users-bounces@xxxxxxxxxx > [mailto:fedora-directory-users-bounces@xxxxxxxxxx] On Behalf > Of Sam Tran > Sent: Friday, June 24, 2005 11:34 AM > To: General discussion list for the Fedora Directory server project. > Subject: 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. -- Fedora-directory-users mailing list Fedora-directory-users@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-directory-users
