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 <[email protected]> wrote: > On Tue, Aug 3, 2010 at 01:35, Randall Leeds <[email protected]> > 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 >
