Re: extensible metadata patch

[Colin Walters <walters verbum org>]

Ok, now that the GPG work has landed, I've filed 

https://bugzilla.gnome.org/show_bug.cgi?id=709050

Where I've started to clean up the sizes work.  I changed a few things
with the first commit:

* Make the checksum binary, not ASCII for space efficiency, and matching
  the other objects
* Change the sizes to unsigned 't' not signed 'x'
* Sort the checksums, just in case we want to bsearch on them later
* Drop legacy bits that were around to write a separate .sizes file; it
  is now ostree.sizes in the in-band metadata
* Add a test case (using the GJS-based tests it's a lot easier to parse
  GVariant data)

On Mon, 2013-09-09 at 16:05 +0100, Vivek Dasmohapatra wrote:
> > Let me know what you think!
>
> As long as I can stuff the sizes data in there (has to be a pair of
> size values for each checksummed object for my purposes, but I think
> you knew that), I'm good  with it.
>
> I originally didn't do so because I didn't want to break binary
> compatibility but from skimming the bug you seem to have worked
> around that.
>
> With regards to your earlier comment about commits, I think we can combine the 
> two approches: If we can harvest the commit size data as we do the commit,
> for efficiency, as I do now, we can then use that cache as we traverse the 
> commit so we only have to load filez objects to get the sizes out if we
> dont have a cached value.
>
> Has the advantage of being fast and simple when it can be but correct
> for all cases, and won't normally trigger loading of all the filez objects
> into memory.