> http://code.sixapart.com/svn/memcached/trunk/server/doc/protocol.txt
Thanks for that -- learned something. > No its not reasonable if the bulk of the mechanisms don't support some it > internally (like JPA does). For 3.4, it's better than 50/50 since both JPA and BerkeleyDB naturally support querying. You could possibly build a query API for JBossCache since it does support iteration over cache entries by walking the tree. I've seen no warnings about that operation, but I haven't really looked. For 4.0, I'm not certain whether we'll port BerkeleyDB, so it may leave JPA as the only storage mechanism with natural support for querying. In any case my impression from cas-user posts is that JPA is one of the more popular choices for ticket storage, so we shouldn't be shy about developing features that may provide important or interesting functionality based on it. In the name of generalization, we should consider a QueryableSessionStorage subinterface of SessionStorage that can service queries. M -- You are currently subscribed to [email protected] as: [email protected] To unsubscribe, change settings or access archives, see http://www.ja-sig.org/wiki/display/JSG/cas-user
