[Date Prev][Date Next][Thread Prev][Thread Next]
[Date Index]
[Thread Index]
- Subject: Re: Why not just ONE of each module?? (Re: Lua binding for d-bus?)
- From: Michal Kolodziejczyk <miko@...>
- Date: Wed, 14 Jan 2009 10:43:03 +0100
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