Re: [ANN] nixio 0.3 - System, Networking and I/O library

[steve donovan <steve.j.donovan@...>]

On Mon, Jul 13, 2009 at 11:57 AM, Miles Bader<miles@gnu.org> wrote:
> As a community, what do we do now though?  Nixio undoubtedly improves on
> the aforementioned libraries in various ways, but it does muddy the
> waters a bit, and do-it-all blunder-buss libraries don't seem like a
> very good way forward in general.

It's clear that nixio solves the particular problem very well.
Generally, however, things are in flux.  There was a discussion about
Luiz' proposal for a osex:

http://lua-users.org/lists/lua-l/2009-05/msg00470.html

i.e. answering the question 'what basic cross-platform OS
functionality can we package in a library'?  lfs is cool, but I miss
things like access (which IHMO should be part of lfs), so I go to
lua-ex, but this has an ad-hoc approach to modifying system namespaces
(like os) which feels dirty.  The consensus was that adding things to
os is not necessarily evil, but there should be agreement as to what
extra functions should live here, and what their parameters and return
values should be. For example, os.sleep() is a nice candidate for an
external function, easy to implement on most OSses, but the
specification should be clear on what the meaning of its argument
should be (milliseconds? fractional seconds?)

Another theme of that thread is that it's easy to work at the wrong
level of abstraction when designing such a library, overfocusing on
the platform implementation.  For instance, the lfs pattern of
iterating over entries in a directory is very efficient on POSIX, but
this pattern isn't the most efficient way to do it on Windows if you
then have to stat each filename, since the _find_next function is
actually grabbing more than the file name - so an alternative iterator
over file entries turns out to be needed.

lua-ex is not bad at what it does, it does provide a portable Process
abstraction, etc.  However, it has recently been growing in some
ad-hoc ways; when I was packaging it for Lua for Linux, I found myself
stripping out the new path manipulation functions since they don't
need to be in C and were a bit .. eccentric.

steve d.