Natanael Copa wrote:
I agree. I would also like to help if it was possible.
Here are some things I have been thinking:
1. Make a comparison table of all funcions in ex,
luafilesystem, lposix
and maybe even their equivalent in apr as reference.
http://lua-users.org/wiki/ExtendedApi
Please feel free to add APR into the comparison mix. I
don't know much about it.
2. Make the API. Decide what functions should be
included and what the
names should be
The "ex" API was and is intended to be a proposal for an
such an API. It provides "standard" O/S facilities beyond
what standard C (and thus Lua core) provides.
3. Create the lib.
"ex" already has two implementations one each for POSIX
and Windows. They are not terribly clean, have no
included build process, and could stand a review.
4. remove all the funcs implemented in this lib from
lposix and keep
lposix as a posix specific thing for non-windows stuff.
Why remove functionality from lposix? It stands by
itself as a perfectly good POSIX binding for Lua. If
your program is not intended for Windows and will never
target it, instead targeting POSIX directly, it makes
perfect sense to use lposix.
It seems that the biggest strike against the "ex" API is
the fact that it integrates into the Lua io and os
namespaces. It seems many people feel that this may
cause too much confusion for new Lua users.
However, I feel that in order for such an API to be
useful, it must integrate strongly with the core
libraries. The "ex" API currently integrates with the
core libraries in the following ways:
Augmenting the io namespace (io.pipe)
Augmenting the os namespace (many functions)
Augmenting the file metatable with lock() and unlock()
methods
Reimplementing os.getenv()
Redefining os.remove() to remove directories
Returning actual file objects from io.pipe()
The proper way to write a portable, stand-alone Lua
program with the "ex" API is to always require "ex" in
your program, documenting the fact that it will use
extensions to the Lua core. Alternatively, one can
document the use of extension APIs individually:
assert(os.sleep, "This program requires os.sleep")
-Mark
