lua-users home
lua-l archive

[Date Prev][Date Next][Thread Prev][Thread Next] [Date Index] [Thread Index]

On Thu, Feb 28, 2013 at 12:39:05PM +0200, Dirk Laurie wrote:
> Somewhere the thread changed course from not just Ruby vs Lua
> to that reliable old performer, Lua's lack of "batteries".
> I don't think anybody seriously means "like Python."  Python is
> way past "batteries included". It's reached the stage of "any old
> junk repackaged". I've just asked Ubuntu's package manager how many
> packages have "python" and "binding" in their names.
> Python, 342.
> Ruby, 101.
> Perl, 81.
> Lua, 13. None of which I have actually installed.

FWIW, I've started a project "Crow"*, to support a run-time module fetching
system. Basically, you seed your local configuration file with URLs to
package databases, elliptic curve public keys (which can be very short), and
other parameters, and modules which aren't found locally are downloaded
automatically and placed into a local cache at require time.

It'll also support automatic run-time updating, so long-running server
instances can be automatically patched for bug or security fixes--at least
for pure-Lua modules.

This is one reason why I've added so many bindings to OpenSSL in my cqueues
library. cqueues will handle all the asynchronous I/O happening behind a
simple "require" call, and the OpenSSL bindings support signature
verification, including validating chains of trust.

This way, one doesn't have to worry about installing a package locally,
including making decisions like "is it really worth it?" You can just use
the package in code immediately; if you don't like a module and stop using
it, it just quietly disappears.

Because of the way cqueues handles events, the Crow system can be readily
embedded into existing applications, too, without much (or any) adaptation
to the aynchronous network I/O.

It's also not centralized. This is why public-key crypto is built-in at the
core. And I'm striving to make the tools to generate keys, and package and
sign code as trivial to use as possible. I imagine people (like myself) who
prefer to host their projects themselves can just publish a URL and a short
70-character public key for people to copy into their local config file
(with as many constraining parameters as the user wishes, of course). Or
they can federate with centralized repositories using trust chaining
techniques--e.g. signing the repository information for Bob
Smith, restricted to loading bob.smith.* modules.

* I recently registered was already taken. I hope people
are familiar with terms of venery and don't think I'm just a really dark
person ;)