[Twisted-Python] potential connectSSH workflow

[glyph at divmod.com]

On 09:14 pm, paulswartz at gmail.com 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 otheruser at foo.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 :).