Mailing-List: contact dev-help@couchdb.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@couchdb.apache.org
Received-SPF: neutral (nike.apache.org: local policy)
MIME-Version: 1.0
In-Reply-To: <76AF69AA-BEA6-493C-9554-EE74149D162C@apache.org>
References: <1A1A730B-6A6C-4CD6-81B1-58F1D7F4980A@apache.org>
	 <b11e05440904190216r63756c3bh405aa634c205b9c1@mail.gmail.com>
	 <0E06DEA4-4F96-4B85-A632-9789B3FAFD4A@apache.org>
	 <76AF69AA-BEA6-493C-9554-EE74149D162C@apache.org>
Date: Tue, 21 Apr 2009 11:44:39 -0400
Message-ID: <64a10fff0904210844y363edaa6g3d49895dd852d93b@mail.gmail.com>
Subject: Re: Creating attachments from HTML's INPUT type="file"
From: Dean Landolt <dean@deanlandolt.com>
To: dev@couchdb.apache.org
Content-Type: multipart/alternative; boundary=00151750e50a5f6f15046812862d

--00151750e50a5f6f15046812862d
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit

On Mon, Apr 20, 2009 at 11:54 PM, Curt Arnold <carnold@apache.org> wrote:

>
> On Apr 19, 2009, at 7:01 AM, Jan Lehnardt wrote:
>
>
>> On 19 Apr 2009, at 05:16, Oliver Boermans wrote:
>>
>>  ...
>
>>
>>>  Excellent summary, thanks! We're open to enable the API handlers for
>> pure HTML forms with more features, if you can line out what you would
>> want to have.
>>
>> Moving to dev@
>>
>> Cheers
>> Jan
>> --
>>
>>
>
> I haven't had the time I would like to research this adequately.  I thought
> it would good to keep the discussion going, so please forgive any obvious
> blunders.
>
> Feature: End point for HTML form submissions for file uploading
> Use case: Uploading files from browser when their is not intermediate
> layer.
>
> Info that must be encoded somewhere:
>
> database URL
> docID
> rev (for modifications)
> content type of attachment
> content of attachment
> attachment name
>
>
> Possible locations:
>
> database URL: That has to go in the action URL for the form
> Content of attachment: In body of POST request per HTML spec
> docID: Could be encoded in either the action URL, content of a field
> (possibly hidden), or field name.
> rev: Same options
> Content type: The POST request will have a content-type from the browser in
> the header for the file content, however the form author may want to allow
> the user to explicitly specify a content type.
> Attachment name: Name of input type="file" field, names of files selected,
> content of hidden field
>
> Considerations:
>
> Should we provide a mechanism to change the body of the document
> simultaneously.  For example, if there is a field "body", it would be
> interpreted as JSON and replace the current document contents.
>
> A file input control can select and upload multiple files.  If attachment
> name is based on the field name, likely would need to add an index to
> support the case when there are multiple files selected.
>
> The local file names may be missing from the post body, might not be unique
> and might be approximations.  I'd avoid basing the attachment name off of
> them, thought it would be good if they could be preserved.  Any chance that
> they could be added to the _attachments metadata?
>
>
> My current though is something like:
>
> Action URL: http//server:5984/database/_form?multi=true|false
>
> Special field names for docID, rev and body
>
> If multi=true, multiple selections of files would be supported and
> attachments would be named from the field name + [index]
> If multi=false, if multiple files were selected, the request would be
> rejected.  Otherwise attachment would be named after the input field
> For every file input control, if there is another field with that name +
> "content-type", the value of that field would be used for the content type.
>  Otherwise, the content type provided by the browser would be used.
>
>
> Ideally, the local names of the uploaded files would be preserved in the
> metadata for the attachment.
>

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 were
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? 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 with
sharding.

So maybe action server is the wrong word, and I know it could totally get
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?

--00151750e50a5f6f15046812862d--