On remote weaves

[Martin Pool]

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