Transport w/ delta / offset

[Aaron Bentley]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

John A Meinel wrote:
> I was thinking about what would be possible for a smart server
> implementation, and whether it could be done with the current Storage
> and Transport layers.

I don't think it can.  It mars the otherwise-clean separation of
concerns.  I think it makes more sense to have a SmartBranch.

Another option would be to introduce a new BranchStorage interface that
Branch uses, and can be satisfied with either a DumbBranchStorage
interface that uses Transport and Store objects or a SmartBranchStorage
that uses a smart server.

> Or possibly the Revfile format.
> Specifically, Revfile would want to get portions of a file, rather than
> reading in the whole thing. So probably the Transport layer needs to
> have functions for 'getting' only a portion of a file. The local
> filesystem and http both would support just getting a portion of a file.
> You could get() the index files, and then get_partial() the pieces of
> the revfile.

Yes, Martin and I discussed reading revfiles that way at UDU.  It
doesn't look like the revfile format is going to be used, though.  And
the current weave format requires reading the whole file.  There's
nothing wrong with get_partial if it's useful, but since you'll want to
read multiple portions of the revfile, it would be really good for it to
support batch operation.

> For a smart server, you would frequently only want to request a delta,
> and it seems foolish to transmit the full text, just to compute a delta.
> And if you are using a revfile format, you wouldn't want to unpack 2
> full versions, just to combine them back into a delta.
> 
> The problem is that the Storage layer is where you know what to Diff
> against, but the Transport layer is really where you should be doing the
> delta.

> Does this sound reasonable, or is it putting too much intelligence in
> something that is supposed to be low level?

I don't think transports should not be concerned with diffing.  I'd say
that's a branch-level concern.

Aaron
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iD8DBQFC3m8C0F+nu1YWqI0RAmYkAJ9VaahzPz7aE+9YU9rqYhgaszLTGgCdHftc
rTFSnMrX3DBu2FPm7S2rRdE=
=fURN
-----END PGP SIGNATURE-----