Names

[garbados]

Connection -> {Session,Client,Instance,Server}? View -> {Query,Index}?

Lots of folks ( @BigBlueHat @drsm79 @mikerhodes ) have raised concerns about the naming conventions in this library. Let's sort them out here.

[drsm79]

+1 for Session and Index

[garbados]

I'm hesitant about Session because sessions imply very specific things about caching, etc., when in fact all the Connection object is (in @mikerhodes words) is a glorified URL constructor. So, +1 {Instance,Server}

And +1 Index. That's +2, so I'll put it in the Names PR.

[drsm79]

You use a requests.Session under the hood, right?

[garbados]

Yep! Because of how it persists cookies and whatnot across requests. Every object -- Connection, Database, Document, Design, View (soon to be Index), and Attachment -- inherits that behavior from the Resource class.

[drsm79]

Can you see where I'm going with this? ;)

[garbados]

Yep! And I'm still -1, because that Session behavior isn't special to Connection. It feels highly inaccurate to use the name Session for Connection when every object is a Session underneath.

CouchDB-Python and CouchDBKit both call it Server, so +1 Server.

[drsm79]

What about moving the auth stuff into Resource and having Connection be Account (or similar)? Things like active tasks, replications, and all dbs make sense in an Account context more than a Server one IMHO.

[garbados]

Fair, since for Cloudant it's not actually a server at all. +1 Account.

Moving the auth stuff into Resource would give every object (Attachment, et al) would have login methods pointing to nonsense URLs like DB/_design/DDOC/_search/INDEX/login. I don't quite understand the point of moving it.

[drsm79]

Do you see the workflow as:

1. create an Account instance (yay, naming things is fun)
2. log in to the Account, get a session to use for auth to other things
3. pass that session to other things like Documents, Designs, etc.

?

[garbados]

Hmm, actually, -0 on Account. Account has auth implications, too, which won't make sense both for CouchDB and for Cloudant setups using per-user databases, where an account is probably a database.

+1 Instance.

[drsm79]

-1000 on Instance - it's already got a very specific meaning in OO

[garbados]

Workflow:

1. Create an {Account,Instance} instance, perhaps passing it basic auth credentials.
2. Login if you prefer cookie auth.
3. Pass that session object around.

[garbados]

Oh, I see why you'd move auth into Resource. Yeah, that's doable.

[drsm79]

:D :dancers:

[garbados]

OK, given veto of Instance, the Least Incorrect Name so far seems to be Session. I'm willing to implement that.

[garbados]

Seems @drsm79 prefers Account. Willing to implement that. I'll close this when there's a PR for it.