Hi, all~
Now that I've joined Taobao.com's SDS department and will be able to work on OpenResty in a full time fashion, I've just worked out a (somewhat) detailed plan for the next generation of the OpenResty server. Well, sorry, this draft is in Chinese since my $manager reads Chinese better:
http://www.pgsqldb.org/mwiki/index.php/Nginx_openresty_plan (still being actively updated)
After discussing with my friend and colleague
chaoslawful++ for possible designs of a high performance implementation of the OpenResty server, we finally decided to rewrite OpenResty.pm in pure C in the form of an nginx module.
Here's some highlights of the Chinese project plan given above:
* Nginx-openresty will remain fully opensource.
* We want to take full advantage of Nginx's event modle and asynchronous I/O and we don't want backend requests blocking as well.
* We want to integrate Coco Lua into nginx's event model leveraging
coco's C level coroutines, thus leading to transparent asynchronous I/O
on the Lua land. For example, consider the following Lua code
res = http.get('
http://www.taobao.com')
will
automatically yield the current "lua thread" and register a socket fd
to nginx's underlying epoll/kqueue/select/etc model and return control
to nginx to do other things. Once data arrives at the socket fd, nginx
will get informed and accumulated the response data. When the requested
data is completely ready, nginx will resume the pending lua session and
the Lua function "http.get" will successfully return.
* We want Lua to become the first-class embedded langauge on the service level and we'd abandon the restyscript language.
* The first two backends we want to implement for nginx-openresty are mysql and Oracle (and Hive afterwards) because these are heavily used in our department's production.
* We'll only allow the HTTP POST method to emulate modification methods like PUT and DELETE. GET will no longer be allowed here to reduce XSS attach risk.
* Password login method will require the client to request a random number from the OpenResty server and use it as a salt to encrypt her password using multi-pass MD5, as in
passwd = md5(passwd)
for 1..2 do
passwd = md5(passwd + salt)
done
* For the REST interfce, we will introduce Type API to allow user use Lua snippet to define new parameter types for Views and Actions.
* For RDBMS backends, Views and Actions can use the "map_to" attribute to map automatically to underlying DB functions and stored procedures.
* Views and Actions' definitions (ako "queries") will specify in the backend's own query language (like PL/SQL, PL/PgSQL, and etc.). OpenResty willl only recognize special interpolated parameters in the form of $(param_name type=xxx checker=xxx default=xxx ...).
* Views and Actions will support "cached" and "expire" attributes to allow caching of result data set, and "async" attribute to allow time-consuming backend queries to submit to remote queues like memcacheq and eventually run by async daemon workers. The original View invoker will immediately get a job ID for his request (unless the task queue is full) and poll OpenResty's Job API for the status of his task and get the final results when the task is marked "done".
* View/Action parameters can specify types, Lua-specified checkers, and default values. For example:
{"name":"my_view","query":
"select * from animals where age > $(age type=integer checker='return age >= 0 and age <= 100')"}
* Filter, Template, and Trigger APIs will also be introduced :)
I'll create a git repository on GitHub for the nginx-openresty's development. Participation will always be appreciated :) I'll keep you posted.
Cheers,
-agentzh
