And now remains only Trean ... #7161

This list is now:

Auth_Signup
trean

... and we'll remove admin/datatree.php in Horde 4 when this is done.

was removed along with Horde_Template

The places left that only use DataTree (i.e., no other driver is 
available) are:

Auth_Signup
admin/datatree.php (doesn't really count, but for completeness)
incubator/faq/
jonah/lib/Delivery (being deprecated once Jonah is branched)
trean

... and some assorted upgrade scripts that should be fine to break in HEAD.

We have a native SQL driver in 3.2. AFAIK the only places where we 
still use DT is Threan bookmarsks and Horde_Auth_Signup.

Note that the only reason this isn't high priority is that Horde 4 
isn't the top priority yet - it will move up to high as soon as 3.2 
and related apps are releases and Horde 4 development is begun in 
earnest.

Making this into a general "get rid of DataTree for Horde 4.0" ticket.

It does work, as long as you don't need to use anything that's in the 
horde datatree tables while using that app, like perms or groups.

No, I only think it might work.

Jan- have you successfully used that idea? I think it'd create 
problems if Nag were to instantiate the Perms driver, etc...

That should be possible already. Try adding lines (and the according 
tables) like this to the applications' conf.php files:
$conf['datatree']['params']['table'] = 'horde_datatree_nag';
$conf['datatree']['params']['table_attributes'] = 
'horde_datatree_attributes_nag';

When we got our performance problem, history was not activated, so 
moving out the history would not be enough. The performance problem 
with the actual permission implementation arise when there are many 
users. Our database server came to a halt after about 4000 users has 
logged in.

We found that these type of requests were the main performance problem:

SELECT c.datatree_id, c.datatree_name FROM horde_datatree c LEFT JOIN
horde_datatree_attributes a1 ON a1.datatree_id = c.datatree_id WHERE
c.group_uid = 'horde.shares.nag' AND ((a1.attribute_name = 'owner' AND
a1.attribute_value = 'myuserid') OR (a1.attribute_name = 'perm_users'
AND a1.attribute_key = 'myuserid' AND a1.attribute_value &
2) OR (a1.attribute_name = 'perm_creator' AND a1.attribute_value & 2) OR
(a1.attribute_name = 'perm_default' AND a1.attribute_value & 2))
GROUP BY c.datatree_id, c.datatree_name, c.datatree_order ORDER BY
c.datatree_order, c.datatree_name, c.datatree_id

When doing an "explain" on the mysql server, it shows that this 
request has to evaluate each time a number of entries roughly 
proportionnal to the number of users in the database (since each user 
has at least one share for each type). If each type of shares had its 
own table (horde.shares.nag, horde.shares.kronolith), it would not 
have to do the left join and generate a temporary table each time, and 
it would probably better use the indexes.

If you have another way (other than changing the database structure or 
use session caching) to improve the performance of the permission 
system with thousands of users, I'm all ears!  Right now,we are 
stucked with horde 2.2 because of this problem :(

The permission system was one of the main reasons for writing the 
DataTree backend, and we need a tree structure for permissions. Also, 
now that history has been moved out, permissions is (almost) the only 
thing left that uses DataTree.

Database queries for permission data in the datatree become really too 
slow when the user base reach many thousands users. Moving the 
permission data to its own table with proper indexes would greatly 
improve performance of the permission system.