On Tue, 01 Dec 2009 16:58:50 -0600 Eric Evans <[email protected]> wrote:
EE> On Tue, 2009-12-01 at 15:38 -0600, Ted Zlatanov wrote: >> I disagree, why would you want to forbid switching the keyspace? That's >> turning off a currently working feature. Also, connections are not >> free, especially across WAN links. EE> Because it makes a mess out of an API that already confuses people. And EE> again, I posit that this is a corner case, something that very few EE> people will actually want to do. We should be optimizing for the common EE> case. On Tue, 1 Dec 2009 17:13:24 -0600 Jonathan Ellis <[email protected]> wrote: JE> It's a currently working feature that (a) only exists in the first JE> place because it was less bad than postponing 0.4 until we could add JE> something like this auth feature, and (b) is of entirely theoretical JE> benefit in the sense that nobody who wants to keep it actually has an JE> app using it, to the best of my knowledge. JE> Let's correct our error, and only add functionality that we know is JE> really needed -- and even then, only if the benefit outweighs the JE> complexity price -- rather than waving our hands and saying "maybe JE> someone will need it, someday." That way leads to clutter and bloat. OK. So what should the API be? Just one method, as Robin suggested? void login( Map<String, String> credentials, String keyspace ) throws AuthenticationException, AuthorizationException In this model the backend would still have login() and setKeyspace()/getKeyspace() separately to distinguish between authentication and authorization but the frontend API would merge them. This means the keyspace parameter will be removed from all the current Thrift API calls and application will need to remember what keyspace they requested. It will definitely not make 0.5. Let me know if this is OK and I'll prepare a new patch. Thanks Ted
