lua-users home
lua-l archive

[Date Prev][Date Next][Thread Prev][Thread Next] [Date Index] [Thread Index]


>Just thought I'd  better do the right thing 
>and submit my patch to the lua socket library.

Now you mention it, here's a related feature request
for the next LuaSocket. For line-by-line reading, allow
an additional numeric parameter for the max no of
bytes to read. Return at EOL or after max bytes,
whichever comes first. This avoids the need for yet
another (Lua) level of buffering whilst preventing
badly behaved line-based TCP clients (some Outlooks 
spring to mind) which send more data than the RFC
allows, and possibly very much more. (Have seen
Outlook/Exchange msgs with 'lines' 2MB long or more.)

Some way of knowing which reason ended the receive
would be needed, of course, so you know whether
you got a full line or not.

Another featurette which could be considered as a
generic version of your patch is to have a single char to
specify the EOL char (you would just use a 
zero byte). Reason for this is the occasions when
you want to know exactly what line of chars was sent
in a line-oriented protocol. The current definition of
a line is very convenient but does not allow exact
reconstruction of the input data (since CRs just before
LFs get silently eaten), so you can't, for example, 
use line oriented LuaSocket reads to write a mail server
with  a 'strict EOL enforcement' -- lone LFs not
allowed -- option) and simply strip the CRs yourself.

Couple of simplish ideas.