On Wed, 2 Dec 2009 15:32:35 -0600 Jonathan Ellis <[email protected]> wrote:
JE> 2009/12/2 Ted Zlatanov <[email protected]>: >> I'd still rather pass something back. As I said, it allows backends to >> maintain state when it makes sense to do so and can alleviate the >> problem of redundant auth queries in the future. JE> That makes no sense whatsoever. Backends can maintain state or not JE> either way; adding a token you have to pass back makes just adds an JE> extra layer of mapping token -> real state in the simple case of JE> token-is-only-valid-per-connection and an unreasonable amount of JE> complexity if you try to make it valid across more than one. JE> I'm -1 in the apache veto sense on the token idea. On Wed, 02 Dec 2009 15:38:14 -0600 Eric Evans <[email protected]> wrote: EE> If not for SSO via shared-state between nodes, then for what? Can you EE> give a tangible example of "when it makes sense to do so"? Are you sure EE> this isn't YAGNI? Across nodes, backends can't maintain state easily, and even across threads it's not trivial. My version allows a distrubuted application to authenticate once and then reuse the same AuthenticationRequest, as long as the authentication backends have a permanent token store inside or outside Cassandra. If we're going to make the keyspace choice sticky per connection, we should allow for a way to open multiple connections to multiple keyspaces without necessarily hitting auth services every time. You claim the complexity is unreasonable. I disagree. If any complexity emerges, it will be in the backend code which a particular organization may need and will write. For Cassandra itself this is not an issue and the default case (AllowAll) will not create any such complexity. Ted
