Re: Minimal changes version of new summary format for flatpak

["Colin Walters" <walters verbum org>]

On Thu, Oct 8, 2020, at 11:09 AM, Alexander Larsson via ostree-list wrote:
> I've been doing some research on the summary dicussions from
> yesterdays meeting, and it looks like the minimal changes we need for
> flatpak to do its own summary format is pretty small, while being very
> flexible.

Nice!  That said I wanted to also dig a bit more into a thread that was raised in the discussion: What if we 
think of this as structuring things so that a summary is unnecessary unless you want global state (list of 
all refs for example).

> First of all, flatpak already always resolves refs to commit ids
> before calling ostree to pull, so the summary file is only needed
> by ostree for these things:
>  * Finding deltas
>  * List all refs if we are mirroring
>  * Quick access to "mode" and "tombstone-commits" options, otherwise
>    it has to download the config file separately.

Right...hm, this is global state but it should be cacheable for a long amount of time.  Once we use etags we 
could probably go back to fetching the repo/config but just cache it?  And perhaps if we have a cached 
version, go ahead and do further requests (i.e. avoid a blocking roundtrip for this).

>  * In the p2p code (ostree_repo_find_remotes_async) we use the
>    commit timestamp extracted to the summary metadata to find the
>    peer with then most recent version.
>    This is not used by flatpak (anymore).
>
> So, my proposal is that:
>
>  * We merge support for deltas outside the summary. Unless you 
>    specially configure it ostree still adds deltas to the summary for 
>    backwards compat.

Here's an alternative idea: this is out of band metadata keyed by a commit - but we already have detached 
metadata for commits.  Why not store delta metadata with that?  If we properly implement etags (per 
https://github.com/ostreedev/ostree/pull/2205 ) then it'd be cachable.  Now this metadata isn't very useful 
on the client once it's downloaded, but eh...I don't think it will be very large.