Return-Path: Delivered-To: apmail-couchdb-user-archive@www.apache.org Received: (qmail 39803 invoked from network); 12 Mar 2010 22:48:32 -0000 Received: from unknown (HELO mail.apache.org) (140.211.11.3) by 140.211.11.9 with SMTP; 12 Mar 2010 22:48:32 -0000 Received: (qmail 3061 invoked by uid 500); 12 Mar 2010 22:47:53 -0000 Delivered-To: apmail-couchdb-user-archive@couchdb.apache.org Received: (qmail 2952 invoked by uid 500); 12 Mar 2010 22:47:52 -0000 Mailing-List: contact user-help@couchdb.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: user@couchdb.apache.org Delivered-To: mailing list user@couchdb.apache.org Received: (qmail 2944 invoked by uid 99); 12 Mar 2010 22:47:52 -0000 Received: from nike.apache.org (HELO nike.apache.org) (192.87.106.230) by apache.org (qpsmtpd/0.29) with ESMTP; Fri, 12 Mar 2010 22:47:52 +0000 X-ASF-Spam-Status: No, hits=0.0 required=10.0 tests=FREEMAIL_FROM,RCVD_IN_DNSWL_NONE,SPF_PASS,T_TO_NO_BRKTS_FREEMAIL X-Spam-Check-By: apache.org Received-SPF: pass (nike.apache.org: domain of paul.joseph.davis@gmail.com designates 209.85.211.196 as permitted sender) Received: from [209.85.211.196] (HELO mail-yw0-f196.google.com) (209.85.211.196) by apache.org (qpsmtpd/0.29) with ESMTP; Fri, 12 Mar 2010 22:47:45 +0000 Received: by ywh34 with SMTP id 34so1039957ywh.17 for ; Fri, 12 Mar 2010 14:47:24 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :from:date:message-id:subject:to:content-type :content-transfer-encoding; bh=ACiAO6jktMWDG93T00CtmjfFo62Twj7oa4V7xjBqgT8=; b=aFaMf+D0Dn2fkkPmdEpUBfqRGghw+HNNNmmzoHHaoo6Fe3bJnjEnDPMOE7/iOgte1p sUNkW3bIGBrIuVJoLNquWvKwHX0GAHy34YeNxzJofwIRlAJhaEu1AFLCILOG4ZCQm0Q+ Y3D061lx+rGU6N+TIsJpI6abhrcyxSoDRavq8= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :content-type:content-transfer-encoding; b=WqJx2o/TpetetClHDfK4jqhNeduSJXRAkRVHzNN0Pa7GVIUNgHYowHcTzwLPMDYZ6k YM3NI6qQxYJ1dGRyNy9fMxj31eE+XAgtZIbut5msyA/OotQvQP9l89HwDt2xSpXFW149 DvjLNcJD6ilsX+VS/i1JA9byrktJNMpq3GDqk= MIME-Version: 1.0 Received: by 10.101.51.7 with SMTP id d7mr2346950ank.201.1268434041131; Fri, 12 Mar 2010 14:47:21 -0800 (PST) In-Reply-To: References: <4B963F0A.50601@bclary.com> <9CBEF3A7-4C8E-4CFC-A5FA-CF192EEF6457@apache.org> <4B98E2DC.8090906@bclary.com> From: Paul Davis Date: Fri, 12 Mar 2010 17:47:01 -0500 Message-ID: Subject: Re: Problems with large inline attachments with 0.11 To: user@couchdb.apache.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Virus-Checked: Checked by ClamAV on apache.org On Fri, Mar 12, 2010 at 5:26 PM, Benoit Chesneau wrot= e: > On Fri, Mar 12, 2010 at 9:14 PM, Adam Kocoloski wro= te: >> Regardless of the efficiency of term_to_binary, there's really no compar= ison between the standalone attachment API streaming bytes almost directly = to disk and the inline one buffering the whole attachment in memory and inf= lating it by 37% to boot. =A0Definitely use the standalone API if at all po= ssible. =A0Best, >> >> Adam >> > > About that, it would be good to have an option to attach to a specific > revision of a doc without incrementing it. I know that's the reason > why couchapp use inline attachments. Some complained it increases the > number of revisions when you send a lot of attachments. > > What do you think ? > > - benoit > Isn't there a multipart-mime PUT thing now? I don't think the "put attachment without changing the _rev" behavior is a good idea. Paul