When we say that "the Kepler project aims to collaboratively create an extremely portable Web development platform based on the Lua programming language, offering both flexibility and conceptual simplicity." what do we mean?
For those used to the Lua programming language and its community, features like portability, flexibility and simplicity are part of the game, but how can this explain Kepler?
Kepler is not trying to be the new PHP or to take down Python or whatever. Even if that was conceivable, it would make no sense to try. Web development is a huge arena and there is space for everyone, we don't need to expend energy attacking the other players.
Depending on the problem you are trying to solve, the natural tool for it emerges naturally, there is no need to force anything. So assuming the other platforms are good in what they do, why is Kepler different?
The answer is related to the above "mission statement". Being extremely portable while offering flexibility and conceptual simplicity is not an easy to do and this is Kepler's winning point.
Kepler fits
Kepler can run in every system that runs PHP, Python, J2EE or .Net, but it can also run on systems where it would not even make sense to try to install one of those platforms. Have you ever tried fitting PHP or Ruby on a device with 1M RAM? Even if you manage to do it, there is no much space left for application and data.
Surely there are lots of libraries or frameworks that fit into that tiny space, but then those tend to be too low level and to use languages not very appropriated for Web development. Kepler uses Lua and that means having a full fledged language at your disposal from the start.
But then maybe you are not developing for such a tiny device, so why care about memory usage? You've got a point but we think that even if running on a multicore CPU with Apache, Kepler continues to offer the same flexibility and simplicity as in the constrained scenario.
Kepler is modular
This is where its modular Architecture gets into the picture. Instead of having a "one size fits all" model like most of the current web development platforms do, Kepler chooses the opposite direction. You can choose what gets in and what stays out.
Surely that makes things harder for newcomers so we offer a default installation with a common set of modules, but if you prefer to fine tune your setup go ahead! This is more close to a distribution of GNU/Linux where you can choose to just "press Enter" and get Ubuntu or you may want to build from scratch and you get Gentoo.
This modular architecture is used from the very first layer. Kepler can use different lauching models (CGI, FastCGI, mod_lua, ISAPI, SAPI) over different Web servers (Apache, IIS, thttpd, Xavante and others) with different web metaphors (CGILua for a page based generation, Orbit for a MVC based page generation).
Kepler future
We are working on expanding Kepler's power as a web development platform while maintaining its small footprint and flexibility. This is where the Kepler developers and the Lua community kicks in.
The mains areas of interest would be:
A versioned package system that would make it possible to start with a minimal Kepler installation and add modules easily as they become needed, somewhat like apt-get on Debian Linux. For example, after you have Kepler installed you could choose to focus on security issues and then request an AES module using the package system. It would be downloaded and installed automagically. Ruby has Gems, Python has Eggs, Lua will have Rocks (See LuaRocks.)
An ORM (object relation mapping) module that would allow the use of database centric models as the basis of your application models. (See ORM)
A storage abstraction framework that would allow the use of different storage systems (memory, files, databases, SVN) transparently. This framework would make it possible, for example, to start a project managing all objects in memory and then move to an external database if necessary. (See SACI.) Note that SACI is not necessarily an ORM.
A synchronization framework for SACI and ORM in order to allow the application to use the storage abstraction without caring too much about synchornization issues. Kepler applications for example could use this in mobile devices not connected to the internet and then count on automatic data synchronization with other servers when the devices got a connection.
Support for intercommunication between Kepler instances using Lua agents. Lua agents exchange chunk of code and data and that could allow the use of Kepler farms for load balancing, data synchronization or even code execution.
This is still uncharted territory so we are not sure of how to get there. If you would like to help us or suggest new targets please check the Developers section.