lua-users home
lua-l archive

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

On Tue, Nov 19, 2013 at 7:16 AM, Sir Pogsalot <> 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