On Sun, 05 Aug 2012 14:37:02 -0700, Jameson Graef Rollins <jrollins@finestructure.net> wrote:
> On Sun, Aug 05 2012, Peter Wang <novalazy@gmail.com> wrote:
> > diff --git a/devel/schemata b/devel/schemata
> > index 9cb25f5..3df2764 100644
> > --- a/devel/schemata
> > +++ b/devel/schemata
> > @@ -69,7 +69,10 @@ part = {
> >      # A leaf part's body content is optional, but may be included if
> >      # it can be correctly encoded as a string.  Consumers should use
> >      # this in preference to fetching the part content separately.
> > -    content?:       string
> > +    content?:       string,
> > +    # If a leaf part's body content is not included, the content-length
> > +    # may be included instead.
> > +    content-length?: int
> 
> Hey, Peter.  Something somewhere, and probably at least here in the
> schemata, should mention what the uids are (b? kB? KiB? YiB?)

I thought content-length was a MIME header, but it's not.
Anyway, it's the length of the encoded content in bytes.  GMime
doesn't provide an easy way to return the length of the decoded content.

I actually only need an _estimate_ of the decoded size to present to the
user.  Strictly speaking, that requires knowledge of the transfer encoding.
Previously I planned on guessing it from the content-type, but I think
it's better to return the transfer encoding as well (if any).

Alternatively, notmuch could put in more effort to return the exact
length of the decoded content.  But it's a waste of time if no consumers
will use it.

Peter