On 11 February 2010 13:42, Robert Collins <email address hidden> wrote:
> On Thu, 2010-02-11 at 01:54 +0000, Martin Pool wrote:
>>
>>
>> Perhaps we should move them all to bzrlib.servers. Then we can assert
>> that module is not loaded when it is not needed, and we can allow for
>> currently limited servers to grow into being more generally useful. I
>> think we have some intentionally limited transports in b.transport and
>> I don't see that as essentially problematic. It's more important that
>> the class name make its limitations clear.
>
> This sounds fine to me too.
>
> Perhaps bzrlib.transport.servers.* ?
I'd slightly prefer .servers:
1- submodules seem to occasionally cause more annoying python import
behaviour (circularity etc) than sibling modules
2- bzrlib.transport.servers seems a bit longwinded
On 11 February 2010 13:42, Robert Collins <email address hidden> wrote: transport. servers. * ?
> On Thu, 2010-02-11 at 01:54 +0000, Martin Pool wrote:
>>
>>
>> Perhaps we should move them all to bzrlib.servers. Then we can assert
>> that module is not loaded when it is not needed, and we can allow for
>> currently limited servers to grow into being more generally useful. I
>> think we have some intentionally limited transports in b.transport and
>> I don't see that as essentially problematic. It's more important that
>> the class name make its limitations clear.
>
> This sounds fine to me too.
>
> Perhaps bzrlib.
I'd slightly prefer .servers:
1- submodules seem to occasionally cause more annoying python import transport. servers seems a bit longwinded
behaviour (circularity etc) than sibling modules
2- bzrlib.
-- launchpad. net/~mbp/>
Martin <http://