Re: _list behaves weird on start() after using getRow()

[Joscha Feth <jo...@feth.com>]

Chris Anderson wrote:

> This is a known consequence of the implementation. You're not the
> first to notice it. The problem is getRow calls an implicit start.
> Not  ideal, I know. I'll think on how to fix this cleanly. As always,
> patches welcome.

wouldn't it be enough to send the headers just prior to sending some
content,
e.g.

function send(chunk) {
	if(!chunks) sendStart();
	...
}

that would allow for calling getRow without sending any headers and
still force validity if the user decides to use send() without calling
start() first. I could write a patch for that...

regards,
Joscha


-- 

Re: _list behaves weird on start() after using getRow()

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

On Mon, Jan 25, 2010 at 12:39 PM, Joscha Feth <jo...@feth.com> wrote:
> Zachary Zolton wrote:
>
>> Being able to send a flag to getRow, not to flush the response, would
>> work for me so long as I'm still able to change the headers. My
>> initial scenario was being able to redirect from a value in the view
>> rows.
>
> I have got a changed main.js here, which has been reworked, but
> unfortunately I can't find the spot to fix readline() not returning
> when there is no start() sent, yet.
>

I'm pretty sure that this can't be fixed without some work on the Erlang side.

Good news is I think we can fix it without impacting existing
application so that means it can happen between 0.11 and 1.0

> regards,
> Joscha
>
>
> --
>
>
>



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

Re: _list behaves weird on start() after using getRow()

[Joscha Feth <jo...@feth.com>]

Zachary Zolton wrote:

> Being able to send a flag to getRow, not to flush the response, would
> work for me so long as I'm still able to change the headers. My
> initial scenario was being able to redirect from a value in the view
> rows.

I have got a changed main.js here, which has been reworked, but
unfortunately I can't find the spot to fix readline() not returning
when there is no start() sent, yet.

regards,
Joscha


-- 

Re: _list behaves weird on start() after using getRow()

[Zachary Zolton <za...@gmail.com>]

Being able to send a flag to getRow, not to flush the response, would
work for me so long as I'm still able to change the headers. My
initial scenario was being able to redirect from a value in the view
rows.

Cheers,
Zach

P.S. I guess we should move this conversation over to the dev ML

On Mon, Jan 25, 2010 at 10:50 AM, Joscha Feth <jo...@feth.com> wrote:
> Joscha Feth wrote:
>
>> that would allow for calling getRow without sending any headers and
>> still force validity if the user decides to use send() without calling
>
> I see the problem now :) - chunks added to the queue are streamed to
> the client on each getRow() call, there is no real buffer - thats why
> it is needed to send the client in advance to any additional call to
> getRow().
>
> What about an additional function hasRows() instead - that should do
> the trick to at least find out if there are rows at all, which should
> help in 90% of all the cases.
> Another option would be an additional flush() method which would allow
> flushing the chunk buffer on the user's choice - that would also be
> consistent with how output streams are handled in other
> applications/languages.
>
> I think a combination of both would be best - defaulting to flush() on
> every call to getRow() for inexperienced users, with a flag to disable
> immediate flushing and let the experienced users decide when they want
> to flush.
> Together with an hasRows() method which does not send any headers this
> should be a good solution for everyone. Thoughts?
>
> regards,
> Joscha
>
> --
>
>
>

Re: _list behaves weird on start() after using getRow()

[Joscha Feth <jo...@feth.com>]

Joscha Feth wrote:

> that would allow for calling getRow without sending any headers and
> still force validity if the user decides to use send() without calling

I see the problem now :) - chunks added to the queue are streamed to
the client on each getRow() call, there is no real buffer - thats why
it is needed to send the client in advance to any additional call to
getRow().

What about an additional function hasRows() instead - that should do
the trick to at least find out if there are rows at all, which should
help in 90% of all the cases.
Another option would be an additional flush() method which would allow
flushing the chunk buffer on the user's choice - that would also be
consistent with how output streams are handled in other
applications/languages.

I think a combination of both would be best - defaulting to flush() on
every call to getRow() for inexperienced users, with a flag to disable
immediate flushing and let the experienced users decide when they want
to flush.
Together with an hasRows() method which does not send any headers this
should be a good solution for everyone. Thoughts?

regards,
Joscha

--