Re: About luasocket and receive(..) patterns

[Diego Nehab <diego@...>]

Hi,

> > add it back yourself may be ?
>
> You can't, you don't know whether it was a CRLF or just a
> LF, or where CRs were dropped.

LuaSocket uses a definition of "line" that works well in the
scenarios that were most common in our practice. That is, a
line is terminated by an LF or CRLF. Any CR that may have
been lying around is also eliminated. This makes for a
simple implementation that does not require look aheads and
that supports both LF, CRLF, and LFCR conventions, as long
as there are no CR singletons that you care about. I think
this is a reasonable price to pay.

> To OP: I think you'll have to read fixed size blocks,
> setting the timeout to zero, and when it fails to read all
> the data get the partial block from the third argument.
> luasocket is pretty good, but can get quite hard to use
> outside of the IETF line oriented protocols it appears to
> have been designed for.

That's right. If the definition of line you have to deal
with is different, I think the Lua solution is to write your
own abstraction that reads blocks (in non-blocking mode) and
splits the blocks into lines according to whatever convention 
you want. The last few bytes that are not part of a complete 
line can be fed back into the receive call so they get returned 
along with the next block. Rinse and repeat.

I could certainly have written a more general scheme, but
it's all a matter of where you draw the line.

Kind regards,
Diego