[Date Prev][Date Next][Thread Prev][Thread Next]
- Subject: Re: LuaForge is down and will be for some time
- From: steve donovan <steve.j.donovan@...>
- Date: Fri, 9 Oct 2009 08:19:50 +0200
On Fri, Oct 9, 2009 at 8:03 AM, Alexander Gladysh <firstname.lastname@example.org> wrote:
> After all, who and how would decide that given two libraries are duplicates?
This is the big question. We have no benevolent dictator, nor would
we put up with one, since we are a bunch of cats. The hope is that
Darwinian selection would separate the good ones from the bad ones,
but natural selection can take time ;)
It _does_ confuse the newbies, that's for sure.
> Instead of discouraging duplication, we should encourage (but not
> force) cooperation between authors.
Sometimes there are different needs. E.g. if I have a simple job that
just needs sqlite, then I would use luasqlite, not luasql, even though
that has a sqlite backend. If I miscalculated the scope, then sure
I'd need to 'upgrade' but hopefully I was sensible enough to separate
my main app logic from the database side.
There's another side to the duplication story. Obviously luafam and
linotify are different, because they target different libraries. But
they provide the same service, which is file system notification. I've
been thinking of doing a similar wrap of the equivalent Win32
functionality, but then the problem gets magnified. A person wanting
to write genuinely cross-platform scripts would have to have separate
bridging modules to use these different facilities. Writiing a
rockspec for such a program reveals the complexity of its
dependencies. So in this case there's a case for unified API modules
which use whatever provider is available for the particular system,
call it LuaFileEvent or whatever. (It's a good argument for luasql as