Or don't cache it at all, now that we have the null driver, or maybe 
once we integrated the better-performing sql driver.

Seems like we could either cache the group globally, or the access 
info in the session.

We are storing the entire objects in session. Imagine a group with 100 
members, is really big. So all users will have this group in their 
session. But they need to know only if they are in this group or the 
list of groups they are in. So why we don't cache only this "end 
data", not entire objects and recheck them every page load? Will save 
some time and a lot of session memory.

Having the abstract Group API separate from the null definition is 
fine too, though I agree that the datatree def should move into its 
own subclass.



I've committed this as the "mock" driver. Thanks!

Sorry, I don't follow. Is that a response to what I've written? Or 
just a general rant? And what are you actually saying?

Looking better session objects are abused in the current driver 
implementation. We normally just check if a user is in specified group 
(ex. in perms) or its membership (ex. in shares). So instead of 
storing the call results, is being stored all linking groups objects. 
That grows fast with large installations making session data bigger 
without any special need as other calls are manly if not all 
administrative.

Though this null driver is definitely the most simple solution, it 
*feels* more correct to implement the "null functionality" in the base 
class and move the datatree code into a separate driver instead.

Besides that, I wonder why we didn't add such a driver earlier. It's 
simple enough to even get merged to FW_3, and we can swap the null and 
datatree driver in HEAD.

Even the groups data are cached in session, for installations not 
using groups this means additional objects creation, DT SQL queries 
and writing of session data. Null driver just returns empty values to 
avoid not needed load for sites not using groups.