Ted, Why pass a map of credentials? Why not follow the standard approach of opening the connection with the credentials, as in tr.open( uid, passwd )? For now, that can be an overloaded method call that would leave the existing API as-is.
Robin. -----Original Message----- From: news on behalf of Ted Zlatanov Sent: Thu 12/11/2009 08:59 To: [email protected] Subject: Re: Cassandra access control On Thu, 12 Nov 2009 10:49:59 -0600 Jonathan Ellis <[email protected]> wrote: JE> On Thu, Nov 12, 2009 at 10:42 AM, Jonathan Mischo <[email protected]> wrote: >> > Let's keep it simple. Forcing multiple connections from a purely >> > hypothetical use case is a no-brainer tradeoff. Connections are not >> > expensive. >> Even if we can do it sensibly? Connections aren't hugely expensive, but >> they're not free, either. JE> I suppose, but if it requires sending a keyspace param w/ each call, JE> then it's not sensible. You waste far more overhead for that in the JE> common case -- serializing, deserializing, checking that it's been JE> authed -- than you gain from not having another connection in the JE> uncommon one. JE> I would be okay with being able to send a 2nd auth call to an existing JE> connection to switch the "current" keyspace, similar to how rdbmses JE> only have one active schema at a time. How about: login(Map<String, String> credentials) throws CassandraAuthenticationSecurityException setKeyspace(String keyspace) throws CassandraAuthorizationSecurityException and then all the existing API calls won't have a Keyspace parameter as previously discussed. This works for everyone, I think, and separates authentication from authorization nicely. Ted
<<winmail.dat>>
