Re: next release

Ok I have tested and fixed all examples (partly with the help of all 
numerous users that helped debug thing - thx alot!). All bug reports 
have been attended to and closed with the noteable exception of the 
issues Jan is working on locating atm (thx Jan for your patience!).

I have also updated the roadmap for both the client and the admin. only 
minor improvements and updates. However let me briefly make it clear how 
things are looking.

The API is still not safe from BC breaks!
The next release will however bring this topic to and end. I dont 
envision very large BC breaks however. The goal of the next release is 
to expand caching.

The end result should enable people to easily implement all sorts of 
caching approaches in the client like:
- no caching ;-)
- caching inside the session
- caching using Cache/Cache_Lite where the cache
  * is deleted on change in the admin api
  * is regenerated on change in the admin apo
  * where the cache is regenerated "manually" (like regenerating the 
cache every 24 hours or doing low load)

This is covered quite well with our current structure and will not need 
any BC breaks.

We will also make it possible that during the login method only the 
mapping between auth and perm users is done. all user permission data 
will only be read on demand. the resulting data can then be cached as 
noted above. the advantage is that using this method you can handle 
systems where users have alot of rights/group assigments without having 
to load all of this data on every request from the database or cache.

This is not yet really considered in the current design and may need 
some BC breaks, but I am not yet sure.

Inside the admin api we will make it possible to cache the generated 
queries, generated results with similar mechanisms like the client

Once we have this feature we will be ready to serve any sort of 
performance relevant scenario I can think of. Any assistance from people 
who are maintaing high traffic sites will be much appreciated.

regards,
Lukas