jchris came up with a change to the getRow() API that would allow us to
implement it on top of non-blocking IO systems.
forRow(function (row) { ... })
this style API could also be used in the update function to call a save and
handling success/error conditions.
save(function (error, resp) { .... } )
And then the update function can return any headers and response and get
access to the success/error conditions of the update in the callback instead
of in the initial update function call.
This would require *substantial* changes to the view server protocol since
the update call essentially returns a reference to itself and the view
server can now accept a validate_update_doc call and then will need to call
back in to the referenced update function held by the view server.
-Mikeal
On Mon, Aug 2, 2010 at 11:49 AM, Mikeal Rogers <mikeal.rog...@gmail.com>wrote:
> Back up a few steps.
>
> The view server line protocol while being terribly defined and taking
> breaking changes in almost every release has still maintained a fair amount
> of alternate implementations in languages other than JavaScript. I seriously
> doubt that we would see this kind of diverse additions to CouchDB if the
> barrier to integrating was writing erlang. We shouldn't fix fundamental
> problems with the view server protocol and architecture solely by moving it
> in to erlang.
>
> I'm also *highly* skeptical of the perceived performance benefits of moving
> the js in to erlang compared to moving away from full JSON parsing and just
> doing selective parsing/validation and storing the JSON string as opposed to
> the native erlang representation. I can write this idea up in greater detail
> in another thread but the native JSON parser in *any* language is likely to
> be faster than something that parses the native erlang terms so it's only
> faster on the erlang side to not hit the serialization again which we would
> get if we stored the string+parsed underscore properties instead of the full
> native erlang terms.
>
> Not to mention the security and durability considerations of moving the
> view server in to erlang. There is a reason erlang views aren't enable by
> default.
>
> -Mikeal
>
>
> On Mon, Aug 2, 2010 at 11:39 AM, Jason Smith <j...@couch.io> wrote:
>
>> On Tue, Aug 3, 2010 at 01:35, Randall Leeds <randall.le...@gmail.com>
>> wrote:
>>
>> > Either way we're waiting for a response from couch to call back into
>> > JS, it's just whether we're calling the original function or the
>> > continuation.
>> > I don't have a strong preference either way, but I do slightly favor
>> > the callback continuation as a mild style preference.
>> >
>>
>> I have to say, callback style is way nicer. I have not thought about how
>> that would look from non-Javascript query servers though.
>>
>>
>> > In either case, do we have to add some new response format so the
>> > query server can say "Hey call me again and tell me what to do with
>> > this result?"
>> > In other words, both of our suggestions can work on top of the same
>> > change that needs to happen to the view server line protocol, so you
>> > can code up either one and we can settle on what it should look like
>> > to people writing update handlers later, no?
>> >
>>
>> I suppose so. But I am unclear because earlier in the thread I posted
>> working code that allows me to handle save conflicts (or validation
>> failures) from within javascript, with no change to the line protocol.
>> (That
>> is about all it has going for it in fact!)
>>
>> --
>> Jason Smith
>> Couchio Hosting
>>
>
>
