Re: extensible metadata patch

[Colin Walters <walters verbum org>]

On Mon, 2013-09-09 at 18:17 +0100, Vivek Dasmohapatra wrote:
> On Mon, 9 Sep 2013, Colin Walters wrote:
>
> > While this would increase the cost of the initial download of a commit
> > before we can even show them whether or not there's an OS upgrade, if
> > they do choose to take it, it'd be a lot more efficient than fetching
> > all of the individual metadata objects.
>
> I think on the whole your current design wins over packed commits
> (although of course this depends on the exact ostree usage pattern):
>
>   - Fetching just the metadata is a big win, the user/system can decide
>     if the download is one they want/can-afford to download right now.

Ah for "packed" commits I meant just metadata (i.e.
commit/dirtree/dirmeta), not content.

The cost of packing all metadata together is that in a continuous
integration scenario like gnome-ostree, we'd end up duplicating storage
space for a lot of dirtree objects.  Particularly if your repo has a
high branching factor, this could get costly.  Or maybe not...I need to
measure.

>   - Being able to work out that you only need certain objects (and how big
>     they are) based on the metadata alone is even nicer.

Right, definitely!  Handling efficient downloads of both content as well
as metadata is a use case for the static deltas stuff I am slowly
working on ( https://git.gnome.org/browse/ostree/log/?h=wip/delta )

I'll probably defer network efficiency to static deltas.

Anyways, so I pushed that commit patch, let's see if we can rebase and
get both the sizes and gpg integrated.