Etan Reisner wrote:
On Wed, Jan 14, 2009 at 08:05:01AM +0200, Asko Kauppi
wrote:
As a generic comment, I think it would finally be time
for Lua community to
develop this kind of modules in an organized fashion.
There's so many of them. D-BUS. Cairo. SDL. Multiple
incompatible and
partial modules instead of a One that would be
co-managed by the community.
I think this is where we go wrong, and which keeps Lua
back as a language.
-asko
I agree about the need for organization of this sort of
thing, but I doubt
it much keeps lua back as a language though (unless you
want to claim that
with the organization we'd have fully formed working
bindings for these
things already which would be, I think, something of an
exaggeration).
I agree that community support would be extremly
helpful. There is
plenty software for lua, but if it is not on the
luaforge, it could be
hard to find it.
I think the way to go would be to:
1. create a "lua open software repository" (LOSR) which
would list all
known libraries, its homepage, status, short
description.
It would be ideal if anyone could contribute (filling a
web form, or
uploading a simple text file). Possibly it could be
based on luarocks,
so people could upload their rockspecs, and possibly
source tar.gz
archives. I like the way the archlinux'
aur.archlinux.org works.
2. I always hoped that eventually there will be
"community supported
library" (something like perls' CPAN, so CLAN for lua,
or PHP's PEAR),
which would provide a global namespace for each
module/library (like
Graphic.Cairo. Graphic.SDL etc). This again could be
based on luarocks
(the "more official" repository)
3. So I think it would be best to choose some libraries
(those which are
in "workning state") from LOSR and assign them a place
in the CLAN
hierarchy. I imagine the process should be similar to
what Lua for
Windows guys are doing - there should be as many
different versions in
LOSR as people can create, but only one module at given
time for any
given funcionality should be "blessed" by CLAN (like
bitlib vs LuaBitOp
issue)
I think the problem tends to be that people work on
bindings like this by
themselves and either are unable to release them or
never get to the point
where they feel like they can share them. So the next
time someone needs
one they have to start their own, and we start the cycle
again.
Very true. For some (most?) projects there is no point
in creating
luaforge project (yet - at this early stage), but the
lua community
could be "informed" about it by creating an entry
describing it in the LOSR.
Regards,
miko
