Re: Creating attachments from HTML's INPUT type="file"

[Curt Arnold <ca...@apache.org>]

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  
>> 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?
>
> 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  
>> 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?
>>
>
>

Is there an open bug report for "action server" or "update handler" or  
any previous discussions.  I 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  
could not be handled browser side.  Would 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 CouchApp.  Would appreciate any advice if I need roll my own  
solution.  Not urgent at the moment, but eventually my client will  
want to see it and I'll be forced to find a solution.

Re: Creating attachments from HTML's INPUT type="file"

[Chris Anderson <jc...@apache.org>]

On Thu, Apr 30, 2009 at 9:21 PM, Curt Arnold <ca...@apache.org> 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 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?
>>
>> 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 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?
>>>
>>
>>
>
> Is there an open bug report for "action server" or "update handler" or any
> previous discussions.  I 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 could
> not be handled browser side.  Would 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 CouchApp.
>  Would appreciate any advice if I need roll my own solution.  Not urgent at
> the moment, but eventually my client will want to see it and I'll be forced
> 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.

-- 
Chris Anderson
http://jchrisa.net
http://couch.io