Re: Lua 5.3 Suggestion: extend lua_(get|set)uservalue() toassociate userdata-to-userdata

[William Ahern <william@...>]

On Tue, Dec 03, 2013 at 11:57:50AM +1030, Claire Lewis wrote:
> From: William Ahern 
> >I'm working on a run-time module loader which fetches modules over the
> >network on-demand[1].[2] 
> 
> This all sounds very interesting.
> 
> Will it support windows (32/64) also?
> 

I won't make it incompatible, but I don't have much Windows development
experience. I'll try to make sure my OpenSSL bindings compile with MinGW and
perhaps Visual Studio 2013--which unexpectedly has come extremely close to
C99 compliance. That should be the only C module strictly necessary. The
networking can be done through hooks. And I don't expect directory
manipulations will be necessary because all the modules can be stored in a
flat directory; it works similar to Plan9's Venti storage system, or Git's
repository layout, where objects are named by their hash value, so you don't
need to mess with directory hierarchies to distinguish modules by their ISA,
OS, version, etc.

But completing the work would have to fall to someone willing to submit
patches. Also, Windows' DLL hell means solutions might be tied to particular
interpreters.

Packaging on most Unix systems is far easier. The one gotcha I've personally
encountered is with FreeBSD and NetBSD, where the command-line interpreter
(or whatever is directly exec'd) must be explicitly linked against pthreads
in order for threading to work, because apparently those systems' threading
libraries can't interpose libc routines at run-time. I've toyed with writing
a simple Lua interpreter proxy which allows specifying requirements like Lua
version, JIT-ableness, linking details, etc. I added some work to my luapath
project to introspect interpreters so that it's easier to install Lua
applications (instead of modules) which can support multiple Lua versions.

But, again, none of that is strictly necessary. The project will stick to
parsing the configuration, hooking into Lua's module loading mechanism, and
implementing all the cryptographic operations. Plus some command-line user
tools for key management and module signing, but which use project APIs so
people can also write GUI key managers.

Hosting repositories will be dead simple because it simply involves hosting
a single JSON-formatted manifest file plus the modules, all stored in a
single static directory. I'll host a repository on my server, but ideally
there'll be a plethera of public repositories, plus private repos. I want to
put off features like authentication chaining to keep things simple in the
beginning. Hopefully the ease of key management will make more a complex
trust network unnecessary. I've done a ton of work with OpenSSL, including
building automated certificate authority and signing services, so I'm hoping
I can make it completely painless.