[MERGE] Split bzrlib/transport/smart.py into several smaller modules.

[John Arbash Meinel]

Andrew Bennetts wrote:
> This patch looks large, but it's just moving code around (and adding a couple of
> docstrings to the newly created modules).
> 
> This moves almost all the classes from bzrlib/transport/smart.py, and moves them
> into modules inside a new bzrlib/smart package:
> 
>   * server.py: SmartTCPServer, and other related classes.
>   * protocol.py: Wire-level encoding and decoding of requests and responses
>     for the smart client and server.
>   * medium.py: The "medium" layer (i.e. means of transmission) that carries
>     the bytes of the smart protocol.
>   * request.py: Basic server-side logic for dealing with requests.
>   
> The remaining transport-related classes are moved to bzrlib/transport/remote.py.
> 
> These abstractions already exist in the smart server code in bzr.dev, it's just
> the code was in one huge file.  This seperation also helps detangle some
> inter-dependencies which weren't clear before.  That is, it's easy to put the
> classes in one big file, but it was hard to pull them apart without tripping
> over circular imports and the like.  So the separation also makes the structure
> of the code clearer, beyond just splitting the code into smaller (and thus more
> readable) pieces.
> 
> This split is the first step to merging the hpss branch, which adds more modules
> to the bzrlib/smart package, and builds on the code already there.
> 
> -Andrew.
> 

I'm happy to see this refactoring land. Though whenever we do something
like this, I wonder about backwards compatibility. Is it okay to break
compatibility for large cleanups like this? Is the 'official' api to
access it in a different way (I don't think it is common for a plugin to
want to grab an existing smart server object, but it certainly might
implement one.)

We've used the statement "we *will* be backwards compatible" in the
past. And we've obviously broken it a bit. (or at least changed what we
expected from callers with the new "must be locked" check.)

I'm fine with changing it to a cost-benefit analysis. (likelihood of
breaking existing plugins versus benefit of refactoring). But we
probably should be clear about what we are doing.

John
=:->