On Fri, 2013-08-09 at 16:47 +0200, Colin Walters wrote:
Hi, On Fri, 2013-08-09 at 15:38 +0100, Vivek Dasmohapatra wrote:I've been given the task of investigating ostree, and adding an index to it so that a client can efficiently determine how big a download of a given commit would be (without downloading all the individual metadata files).It'd be pretty easy to compute the total size of a given commit at commit time, and include that in the already existing metadata a{sv}. However, that doesn't tell you how many objects you already have...which is going to be the common case.
Right, our current thinking with an index (which could be a seperate
file or part of the commit metadata a{sv})), was that it would give you
the list of objects needed for a specific commit and their sizing
information. Once you have that you can work how much data you'll need
to retrieve and store.
For making ostree efficient for major (i.e. non-continuous) upgrades, see this thread: https://mail.gnome.org/archives/ostree-list/2013-July/msg00005.html With a static delta, the descriptor could provide the size of the delta, in addition to simply being a lot more efficient. I started to implement static deltas at GUADEC, and I can post some code relatively soon.
Sounds cool, that would definitely be good to have. But support for the fallback case where static deltas aren't available would still be good to have.
But...what's the high level goal here? Something like an OS updater tool that says "Update available: 45MB" ?
Exactly, having a tool that can say: Hey, There is a new update available, you'll have to download 45MB of data to get it. Oh btw, It will take 70MB on disk, so you have enough free space available. Shall i download? -- Sjoerd Simons <sjoerd simons collabora co uk> Collabora Ltd.
Attachment:
smime.p7s
Description: S/MIME cryptographic signature