Now here is a twist. Instead of the traditional Meta-directory vs Virtual-Directory debate, we may have a Directory vs Virtual-Directory debate. Alex Karasulu of the ApacheDS project left this interesting comment on my post about the Red Hat Directory Server:
One last thing. The VD implementations of today like Penrose, are just hacks without a formal computational basis to them. People trying to get a product to market rapidly to sell a company. We intend to enable virtualization eventually with a solid footing in the LDAP administrative model using this concept of a view. Views, as well as triggers/SPs will enable new ways to easily solve the problems encountered in the identity space. As a teaser just think what could be done in the provisioning space if AD supported triggers? Real technology will yield solid reliable solutions instead of these band aids we’re seeing during this identity gold rush.
Pretty strong words, but the idea behind them is very interesting. Instead of building out a virtual directory, add the same capability by using views and triggers in the underlying DB. Personally I’m skeptical that this could achieve the same level of flexibility for talking to disparate data sources that you have with today’s virtual-directories. But hey, if the ApacheDS guys think they can pull it off, more power to them.
It does seem that this solution would require all the disparate data to be written the same DB that is back-ending the ApacheDS. Perhaps a Meta-directory could be used for this (irony intentional).
Identity Blogger 
My intention was not to trigger (excuse the pun) a Directory vs. Virtual Directory debate :-). I think the Virtual Directory is a valid concept. Thanks for really trying to understand the meaning in my post to your blog though. I should have been more clear. Instead I wanted the community to try harder to consider a theoretical basis to implementing virtualization as well as other features mentioned like Triggers. I’m merely offering some cornerstone concepts in X.500 and LDAP as that basis.
I’m tired of applying different ad hoc approaches based on different products to solve the same problem. Migrating from one tool to another, without a common basis, or any portability in view specifications is resulting in a lot of learning turnover. I’m afraid we’re fragmenting our space of expertise across product specific specialists and that’s not a good formula. Users will eventually get fed up and start mocking the term “Identity Management” as a failed movement and a cliche.