From dev-return-4075-apmail-couchdb-dev-archive=couchdb.apache.org@couchdb.apache.org Sun May 03 20:16:06 2009 Return-Path: Delivered-To: apmail-couchdb-dev-archive@www.apache.org Received: (qmail 67517 invoked from network); 3 May 2009 20:16:06 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (140.211.11.3) by minotaur.apache.org with SMTP; 3 May 2009 20:16:06 -0000 Received: (qmail 57988 invoked by uid 500); 3 May 2009 20:16:05 -0000 Delivered-To: apmail-couchdb-dev-archive@couchdb.apache.org Received: (qmail 57893 invoked by uid 500); 3 May 2009 20:16:05 -0000 Mailing-List: contact dev-help@couchdb.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: dev@couchdb.apache.org Delivered-To: mailing list dev@couchdb.apache.org Received: (qmail 57883 invoked by uid 99); 3 May 2009 20:16:04 -0000 Received: from nike.apache.org (HELO nike.apache.org) (192.87.106.230) by apache.org (qpsmtpd/0.29) with ESMTP; Sun, 03 May 2009 20:16:04 +0000 X-ASF-Spam-Status: No, hits=-0.0 required=10.0 tests=SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (nike.apache.org: domain of jchris@gmail.com designates 209.85.132.240 as permitted sender) Received: from [209.85.132.240] (HELO an-out-0708.google.com) (209.85.132.240) by apache.org (qpsmtpd/0.29) with ESMTP; Sun, 03 May 2009 20:15:55 +0000 Received: by an-out-0708.google.com with SMTP id b6so1828252ana.5 for ; Sun, 03 May 2009 13:15:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:received:in-reply-to :references:date:x-google-sender-auth:message-id:subject:from:to :content-type:content-transfer-encoding; bh=eO88sKmfA/2YptEHaHc5E1IvXue3F1jYRgc//nizAcQ=; b=sFqcHRq4Zy1O8gHguL/I2I3ShrQcIfuhYmk/eLtww57tPS7+ErbIE+g/UFexcN9JC1 +UchWwgUZZOKKYIdlpvQxagPszC4ugqKVnVsHIlQkOweH3PLMQnuU+RqQbsRDvbsfQkE iNqxtSSvJOgZFMiS7vumVMz3BT7YS4Miz+Y0s= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:content-type :content-transfer-encoding; b=aDAnAnYW3aAoqIXM0lvTq9p6bxaSsWJk0K1cCYxEnmNxaw3AG6cgUL7uQaAFSlEac8 vj0kBYRu6RluPfLW2d9f5Wfuv6z5yzSqy+lAIHDO900NdB3HF/Xu7pia/y0hSt42/gh6 b3laiOfYpv3CI2ipfzvoDx5iyKJuDkOuBqWWc= MIME-Version: 1.0 Sender: jchris@gmail.com Received: by 10.100.133.16 with SMTP id g16mr11354432and.40.1241381734430; Sun, 03 May 2009 13:15:34 -0700 (PDT) In-Reply-To: <49DEDAF3-409A-495F-8FC0-EE2479395F4F@apache.org> References: <1A1A730B-6A6C-4CD6-81B1-58F1D7F4980A@apache.org> <0E06DEA4-4F96-4B85-A632-9789B3FAFD4A@apache.org> <76AF69AA-BEA6-493C-9554-EE74149D162C@apache.org> <64a10fff0904210844y363edaa6g3d49895dd852d93b@mail.gmail.com> <49DEDAF3-409A-495F-8FC0-EE2479395F4F@apache.org> Date: Sun, 3 May 2009 13:15:34 -0700 X-Google-Sender-Auth: b492428af5f4a0e2 Message-ID: Subject: Re: Creating attachments from HTML's INPUT type="file" From: Chris Anderson To: dev@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 Thu, Apr 30, 2009 at 9:21 PM, Curt Arnold wrote: > > On Apr 21, 2009, at 10:52 AM, Chris Anderson wrote: > ... >>> >>> This seems like an awful lot of special case weirdness, and there are >>> probably more edge cases than you've identified so far. And this only >>> addresses attachments -- there were some interesting ideas posed on the >>> list >>> some time back about how to do unobtrusive form handling, but there wer= e >>> still were some oddities, particularly around strings vs. numbers and >>> deeply-nested objects. >>> >>> I know this is sacrilege, but wouldn't this be best handled by action >>> servers? >> >> This is the way to go. Not action servers exactly, but an update >> handler, for JavaScript which can translate a Req to JSON for PUT. >> Patches welcome or I'll get to it eventually. >> >>> Of course, you could always bury a form handler in a wsgi or rack >>> app or whatever (even a jack app in js) as an _external, but obviously >>> that's not very portable. Baking action servers into couch is the only >>> sane >>> way to solve this problem for something like couchapps (a jsonp service >>> is >>> out of the question for write ops). And it shouldn't be any trouble wit= h >>> sharding. >>> >>> So maybe action server is the wrong word, and I know it could totally g= et >>> abused (hell, I *know *I would abuse it), but wouldn't it be great if >>> form >>> handling could be embedded in design docs with all the other app logic? >>> >> >> > > Is there an open bug report for "action server" or "update handler" or an= y > previous discussions. =A0I searched JIRA and didn't see it, but the terms= were > generic enough that they matched many entries. > > I was trying to avoid specifying any implementation details, just the > requirements to fill a big functionality hole for pure CouchApps that cou= ld > not be handled browser side. =A0Would be great if it could be handled by > something generic. > > Eventually I will need to address this either by trying my first attempt = to > hack Erlang or by adding an intermediary layer and abandon being a CouchA= pp. > =A0Would appreciate any advice if I need roll my own solution. =A0Not urg= ent at > the moment, but eventually my client will want to see it and I'll be forc= ed > to find a solution. > This is definitely on the roadmap for CouchDB. I'd like to see it in 0.10.0, but I'm hard pressed to find time for writing new features. There has been other discussion on the dev@couchdb.apache.org list about the feature. Grep for _update to find the threads. Creating this feature would mostly involve reusing code that has already been written for _show, _list, and _external. --=20 Chris Anderson http://jchrisa.net http://couch.io