On remote weaves
Martin Pool
mbp at sourcefrog.net
Fri Aug 5 22:37:31 BST 2005
On 2 Aug 2005, John A Meinel <john at arbash-meinel.com> wrote:
> After reading the spec, sftp really just seems like a remote filesystem.
> It has open/read/write/close/lock etc.
>
> I feel that development should proceed on making SftpTransport fully
> utilize the sftp protocol, since it gives us pretty much everything we
> need for handling remote branches like they are local ones (no bzr
> specific server).
Yes, it's very nice, and I agree that we should concentrate on sftp
before doing a smart server.
We can pipeline sftp on a single connection to get pretty fast
performance. Have you looked at all at linking to paramiko?
By the way you should check out the lftp interactive multiprotocol
client, which has a mildly amazing implementation of it with multiple
background jobs run in the background.
> I don't really like plain ftp either. Just thinking that some people
> might have upload space, accessible over ftp, but not over sftp.
> It isn't a priority for me, but if ftp has the same level of support
> that sftp has, it seems it would be possible to make some people
> happy.
You could do ftp over ssl to avoid the password problem, but from where
I stand that's pretty much obsolete in favour of sftp.
> Anything using XML-RPC should be designed as a SmartServer, which deals
> in much higher concepts possibly just plain changesets, possibly
> something else.
Yes, I agree.
> The other part with the current serialized form of changesets, is that
> they are meant to be human readable, not maximally packed for transfer
> and machine understanding.
> It could certainly be easier to pack up Python objects in a pickle, and
> pass them across. I'm guessing that would be less cpu intensive than
> parsing an ascii text file.
Right. cPickle warns that it's not safe to unpack untrusted data, but
for people connected over ssh that's fairly OK.
--
Martin
More information about the bazaar
mailing list