On 09:14 pm, firstname.lastname@example.org wrote:
That makes sense: a ConchConnection object which wraps some of the nonsense that currently lives in t.c.scripts.conch like verifying a host key and finding keys to use.
"Connection" seems like a weird name for that to me, as it applies it is attached to a particular ... well, connection. Connector, maybe? Client? ClientStorage? I guess those names have some pretty serious problems too, but it's worth thinking about a better one.
I still think that passing authentication data in connect() is the right idea, but it can default to using the keys that it finds in ~/.ssh or in a key agent.
I agree emphatically, but both the default and non-default cases are equally important. There's a direct analogue in the user interface: "ssh foo.com" will use your default key or agent, and your default username, and that's 99% of usage. That, of course, doesn't mean you can get rid of "ssh -i mykey.id_rsa foo.com" or "ssh email@example.com", they're both very necessary use-cases.
This also looks like an excellent use-case for endpoints. Please see this ticket: http://twistedmatrix.com/trac/ticket/1442 and see if you have any feedback there.
I think making a ConchClientEndpoint which takes another ClientEndpoint and some authentication data is a good interface, but I'm not holding my breath for endpoints-1442 getting merged to trunk. I'm already depending on at least 1-2 of my branches getting merged :)
Definitely. This should be a separate ticket. In fact, far from asking you to wait for it to be merged, I was wondering if you had any comments on the interface that might come from use-cases that would arise in the conch endpoint implementation that might even further delay it :).