On Nov 12, 2009, at 10:06 AM, Jonathan Ellis wrote:
2009/11/12 Ted Zlatanov <[email protected]>:
Hmm, I thought we were going to limit access to a single keyspace
upon
login. You want to keep allowing multiple keyspaces? That would
leave
the existing API intact (only adding a login function) but requires
an
extra authorization check every time a keyspace is given. Do we
expire
authorizations after a certain time?
If this is going to 0.5 we should keep the existing API intact since
we are very late in the 0.5 cycle (so, it's up to you if you need this
in 0.5). But ultimately we want to drop the keyspace args in which
case the no-auth-configured behavior is that you still send an auth
method call but the auth accepts whatever it is given.
The problem I see with this is that you can't have a single connection
accessing multiple keyspaces at once. I can think of some cases where
having a single connection access and differentiate between two
keyspaces would be advantageous, especially in certain kinds of
reporting applications. Otherwise, you force the creation and
maintenance of multiple connection pools on the client side, which
isn't as resource efficient.
This goes back to the concept we were talking about on IRC yesterday
where a single user may have access to more than one keyspace. If you
authenticate and the system authorizes access to multiple keyspaces,
you should have access to them from the same connection, IMHO, since
that's a pretty well established pattern.
