transports and connections

Martin Pool mbp at canonical.com
Thu Aug 31 05:58:28 BST 2006


On 31 Aug 2006, Robert Collins <robertc at robertcollins.net> wrote:

> > One other thought, though. If we are going to do this, we may want
> > explicit connect/disconnect. Not that it is required, but you start
> > changing when we might raise ConnectionError, since it may happen during
> > a .get() instead of during get_transport().
> > 
> > So it might be good to have a way to explicitly make sure that you are
> > either connected, or fail, so that the exception handling can happen at
> > that time, rather than throughout the code.
> 
> Not really : HTTP can fail at *any time*.
> 
> Making all transports look connectionless will model our lowest common
> denominator well.

Well, any transport can fail at any time, and in the future we might
want to allow any transport to reconnect at any time.  (That wouldn't
work so well when using external SSH and needing user input, but in
other cases it could be tidy.)  We do want to handle those errors at any
time.

So I think the 'expected' place to see errors would be during the first
request on the session (e.g. to read the format).

There might be value in an explicit disconnect to let ssh go away.

-- 
Martin




More information about the bazaar mailing list