Mailing-List: contact user-help@couchdb.apache.org; run by ezmlm
Precedence: bulk
Reply-To: user@couchdb.apache.org
Received-SPF: pass (nike.apache.org: domain of jchris@gmail.com designates
 72.14.220.155 as permitted sender)
DomainKey-Signature: a=rsa-sha1; c=nofws;
        d=gmail.com; s=gamma;
        h=content-type:mime-version:subject:from:in-reply-to:date
         :content-transfer-encoding:message-id:references:to:x-mailer;
        b=naqzgTSEaczQv9zOwwr6zA6oRDn7G1BNCdC+8kRY2MsJd63/eXohPTWCOZrAHZEGU6
         W9bNJWlHMRp8eOY7twzFwuaiv8ZDIL0yn8u2li+NGvsUdPktvnCTyoHQSmCgyKGP34Rb
         7QITtTXTjrYXUJhh7ppMf+x0VG+xUM7Xp00aA=
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Apple Message framework v1077)
Subject: Re: standalone attachments and content-encoding header
From: J Chris Anderson <jchris@gmail.com>
In-Reply-To: <cadf1c691003230640w6b2c05b1x928a489ff12a30a8@mail.gmail.com>
Date: Tue, 23 Mar 2010 09:30:37 -0700
Content-Transfer-Encoding: quoted-printable
Message-Id: <0D875BD6-E3B4-432C-980C-99990FF5A6AE@gmail.com>
References: <20100317202433.GB15544@uk.tiscali.com>
 <e2111bbb1003171523o4f7fb8b4pbca885a752de8dc1@mail.gmail.com>
 <560F52C4-A702-466F-9A7B-227FB3B81C0D@merrells.com>
 <e2111bbb1003171538w27956d12g81647590cd100503@mail.gmail.com>
 <7D81536C-491E-47FC-A2A0-BFEB2E3020B7@merrells.com>
 <ec7a93a1003171552l682d7952v2e4ac6b8c74c9106@mail.gmail.com>
 <20100318121929.GA6866@uk.tiscali.com>
 <cadf1c691003221709w606fa354o5efa18ccad186f08@mail.gmail.com>
 <cadf1c691003221724t37d80866jfbfee766a574a93c@mail.gmail.com>
 <C83A1B0D-B105-4120-B56D-5274E7463FFB@gmail.com>
 <cadf1c691003230640w6b2c05b1x928a489ff12a30a8@mail.gmail.com>
To: user@couchdb.apache.org


On Mar 23, 2010, at 6:40 AM, Filipe David Manana wrote:

> On Tue, Mar 23, 2010 at 12:36 AM, J Chris Anderson <jchris@gmail.com> =
wrote:
>=20
>> So we should make sure our public api will accommodate patches to add
>> support for deflate and compress. This is more important than =
actually
>> supporting those encodings, for now.
>>=20
>>=20
> In that case, if nobody is against it, I'll do a patch that:
>=20
> - removes the ?att_gzip_length=3Dtrue doc query parameter
> - adds the doc query parameter ?att_encoding_info=3Dtrue
> - adds two fields to an attachment stub, only when the doc is queried =
with
> the above parameter, that are "encoding" (currently the value will =
always be
> "gzip") and "encoded_length" (which replaces the "gzip_length" field).
>=20
> This would imply also adding a new extra field to the record #att =
named
> "encoding" for e.g., or better yet, renaming #att.comp to =
#att.encoding
> (currently with only 2 possible values "identity" and "gzip"), which =
in turn
> implies changing the DB file format :(
>=20
> Perhaps those 2 attachment stub properties should be always present? =
Without
> needing that doc query parameter "att_encoding_info=3Dtrue"
>=20

I think it'd be good to keep the file format unchanged (even if the =
names aren't 100% descriptive -- "comp" seems ok for now, if there are =
code comments added.)

It should also be possible to use pattern matching to treat comp =3D =
true as comp =3D "gzip".

Also, I don't think there is a rush on this stuff, just as long as we =
move in the proper direction.

Chris

>=20
>> Chris
>>=20
>>> --
>>> Filipe David Manana,
>>> fdmanana@gmail.com
>>>=20
>>> "Reasonable men adapt themselves to the world.
>>> Unreasonable men adapt the world to themselves.
>>> That's why all progress depends on unreasonable men."
>>=20
>>=20
>=20
>=20
> --=20
> Filipe David Manana,
> fdmanana@gmail.com
>=20
> "Reasonable men adapt themselves to the world.
> Unreasonable men adapt the world to themselves.
> That's why all progress depends on unreasonable men."