Mailinglist Archive: zypp-devel (78 mails)
| < Previous | Next > |
Re: [zypp-devel] libzypp for openSUSE 11.0
- From: Michael Matz <matz@xxxxxxx>
- Date: Mon, 5 Nov 2007 08:59:41 +0100 (CET)
- Message-id: <Pine.LNX.4.64.0711050851490.23011@xxxxxxxxxxxxx>
Hi,
On Fri, 2 Nov 2007, Benji Weber wrote:
Hey, great minds think alike as they say :) Yes, we are actively trying
to do just that with the SOLV files which Stano already mentioned in the
plan. The general plan is to rely on an xdelta/rsync like algorithm,
where we have two possibilities:
1) the requester generates a list of blocks it has, sends them to the
server, that one figures out which blocks are missing, and sends a diff
description to the client, which reconstructs the file.
2) The server generates once (when the file changed) a list of block it
has, client downloads that one, and actively asks for the blocks it
still needs.
3) server pre-generates a set of xdelta diffs from every file revision to
the current one, clients asks for the xdelta matching his own revision,
and updates according to that.
The second solution theoretically is the most attractive one: it doesn't
put high demands (CPU and space-wise) on the server, which still allowing
much smaller downloads.
The first solution would allow a bit better compression, but it remains to
be seen if it's worth it.
The third solution is the ugliest one (engineering wise) :)
Ciao,
Michael.
--
To unsubscribe, e-mail: zypp-devel+unsubscribe@xxxxxxxxxxxx
For additional commands, e-mail: zypp-devel+help@xxxxxxxxxxxx
On Fri, 2 Nov 2007, Benji Weber wrote:
I would like to propose:
- Diffed metadata
Hey, great minds think alike as they say :) Yes, we are actively trying
to do just that with the SOLV files which Stano already mentioned in the
plan. The general plan is to rely on an xdelta/rsync like algorithm,
where we have two possibilities:
1) the requester generates a list of blocks it has, sends them to the
server, that one figures out which blocks are missing, and sends a diff
description to the client, which reconstructs the file.
2) The server generates once (when the file changed) a list of block it
has, client downloads that one, and actively asks for the blocks it
still needs.
3) server pre-generates a set of xdelta diffs from every file revision to
the current one, clients asks for the xdelta matching his own revision,
and updates according to that.
The second solution theoretically is the most attractive one: it doesn't
put high demands (CPU and space-wise) on the server, which still allowing
much smaller downloads.
The first solution would allow a bit better compression, but it remains to
be seen if it's worth it.
The third solution is the ugliest one (engineering wise) :)
Ciao,
Michael.
--
To unsubscribe, e-mail: zypp-devel+unsubscribe@xxxxxxxxxxxx
For additional commands, e-mail: zypp-devel+help@xxxxxxxxxxxx
| < Previous | Next > |