Re: Suggestion: Lua 5.3 -- a facility for creating and manipulting Lua file handles (C API)

[Justin Cormack <justin@...>]

On Tue, Nov 19, 2013 at 7:16 AM, Sir Pogsalot <sir.pogsalot@gmail.com> wrote:
> I had trouble trying to figure out luasocket from its documentation without
> resorting to digging through the source.  I understand that certain choices
> were made to unify the differences between how Linux and Windows error (as
> they use different constant names and values), but I found it frustrating
> figuring out what things like :receive() might return.  Maybe I'm just bad
> at navigating the docs, but I could not find a list of possible return
> values (the error names to compare against). :(

There is no substitute for documentation...

> My reasoning for trying to match C structs is that there are a plethora of C
> networking tutorials and man pages detailing what to expect so it makes it
> very easy for others to figure out what values are in the table under what
> key names -- even if the table seems a bit wonky with how to how one would
> represent that data in Lua.  There are less Lua networking tutorials...

As you mention below it is a layering issue, you need to implement the
structs to layer a nicer layer over the top. For ljsyscall I make the
structs as nice as possible (using metatables) so they behave in a
more Lua-like way but you still get raw struct access as well (eg with
a sockaddr_in sin_port is the raw (network endian) value, while port
is the useful host endian value).

> Your getaddrinfo() does look much nicer :]  I just couldn't decide on how to
> make it friendly -- how I would return a table showing which sock types and
> protocols the remote host supports.  Maybe people only really use
> getaddrinfo() to resolve domain names as they already know they want to
> establish a TCP connection.  My other reasoning was that because my bindings
> are pretty direct, it still leaves the option of layering over it a
> friendlier interface while not keeping things like getaddrinfo() from the
> user.
>
> With luasocket, I found a lot of the time I needed to break user-friendly
> abstractions.  Especially if I wanted to use something other than select()
> or a library expecting a socket:getfd().  I also found the number of socket
> options you can toggle/set a bit limited, though I understand the
> portability behind which options made it in.

For ljsyscall I do provide all the options, but thats because it is
explicitly targeted at particular operating systems, not the portable
subset like luaposix.. But these are the core choices you need to
make.