Google's crawlers not only inspect HTML contents, but also XML contents as well as other media types. Pure JavaScript web sites like http://eeeeworks.org are now in Google via their RSS feed provided by OpenResty:

    http://www.google.com/search?hl=en&q=EEEE+works&btnG=Google+Search

Or the screenshot here:

    http://agentzh.org/misc/google-openresty.png

The second entry regarding api.eeeeworks.org in the result list comes from the OpenResty server:

    api.eeeeworks.org/=/feed/Comment/count/100?user=eeee.Public

This is really exciting.

The google crawler even tried to access the OpenResty API that requires login. Hah!

The Jifty people will find the URLs there very familiar, right? ;)

My talk at the D2 conference was a big success. There's already some interesting discussions over the web. And there has also been a long long debate in my company's mailing list around the new web development mode based on OpenResty. Great!

Unexpectedly, the rants from the opposite side has inspired some more exciting features for OpenResty. One example is the idea of a template API, which can be driven by an arbitrary OpenResty view to generate arbitrary contents, like HTML, JS, or any other thing that you can imagine, thus bringing the representation capability to OpenResty's services as well ;)

The slides that I used at the talk can be downloaded from here:

    http://agentzh.org/misc/openresty-d2.pdf

Or the PPT version:

    http://agentzh.org/misc/openresty-d2.ppt

You can also view the original XUL version in a Firefox browser if you prefer:

    http://agentzh.org/misc/openresty-d2/openresty-d2.xul

Enjoy!

The $boss of the Best Practical company ( http://www.bestpractical.com/ ) and the leader of the Jifty application framework, Jesse Vincent, caught on me on the #jifty IRC channel, asking the potential collaboration between our OpenResty and their new baby, the Prophet product. Here's the related IRC log:

(08:11:00 PM) obra: agentzh: ping
(08:11:10 PM) obra: agentzh: there may be interesting synergies between prophet and openresty
(11:29:11 AM) obra: svn://svn.bestpractical.com/Prophet
(11:30:06 AM) obra: http://fsck.com/~jesse/prophet.osdc.tw.pdf for a rough talk on it
(11:30:11 AM) obra: the app that uses it so far is 'sd'

To me, Prophet looks very interesting. It gives me an impression of a REST svk ;) It supports off-line data checkout and true versioning like Subversion and CouchDB. Frankly speaking, the lack of (native) versioning support in OpenResty has been annoying me :)

Google's BigTable supports a third dimension, namely the timestamp dimension, for data tables by means of their distributed file system. I'm wondering how hard it would be to add "native" versioning support to a relational database like Pg. A (clumsy) solution used by mediawiki works but not efficient enough IMHO.

If we can unify the two different worlds, relational world and version control world including git, that will simply rock! :D

Another intriguing feature in Prophet is the ability of synchronizing multiple data sources automatically. It reminds me of the OpenSync thingy.

Well, well, I think I need to look closer...

I finally get a chance to sit down and compare OpenResty with the recently announced Google App Engine product. I've hesitated to do so in OpenResty's documentation in the fear of comparing apples to oranges. Well, they're very different things from the perspective of a platform engineer.

The key difference might be summarized by the following remarks:

   "We run your applications!"
                       -- Google App Engine

   "You run your applications; we just fill in the blanks with REST"
                       -- OpenResty

For what it's worth, both SimpleDB and CouchDB fall into the same category as OpenResty.

The true buzzword for Google App Engine, however, is the BigTable monster behind it. But unfortunately it's not accessible by means of web services (directly).

Following this reasoning, it would be really really cool if we turn the Google App Engine (thus BigTable per se) into an OpenResty storage backend, just like the existing Pg and PgFarm backends. But sadly OpenResty will have to downgrade into some kind of "reduced mode" in terms of functionalities due to the non-relational nature of BigTable. Joining two database tables (or "models" in Google App Engine's terminology) will result in a map/reduce process immediately, which may well explain why it does NOT have join operations in its GQL language. (Well, feel free to prove me wrong ;)) And that's exactly why developers for Google App Engine have been manually doing lots of stuff which used to be done automatically by a traditional RDBMS, so as to gain amazingly good data scalability offered by BigTable. It's all about balance ;) Other semi-structured data storage solutions like CouchDB and SimpleDB are suffering from similar issues here as well.

It's worth pointing out that I'm by no means saying BigTable is weak. Please don't take me wrong ;) BigTable is indeed a godsend for what it's good for.

OpenResty's PgFarm backend distributes its user data across multiple Pg nodes in terms of "accounts". Joining tables in different accounts on the PL/Proxy servers would be painful and (very) limited as well. It's a fair game :) Just different distribution granularity, isn't it? ;)

OpenResty is a general-purpose scriptable web service platform for web applications, mostly developed by Yahoo! China EEEE Works.

It has its deep root in Jifty's REST design and currently supports standalone Pg and Pg cluster based on PL/Proxy. It is more or less similar to Facebook Datastore API, Amazon SimpleDB, and Apache CouchDB (at least in some aspects). Nevertheless, there's still several innovations in OpenResty for its own right.

I've finally come up with an overview document for OpenResty. The POD version of the document can be found at

   http://svn.openfoundry.org/openapi/trunk/lib/OpenResty/Spec/Overview.pod

A rendered HTML version is on CPAN:

   http://search.cpan.org/perldoc?OpenResty::Spec::Overview

( OpenResty::CheatSheet also provides a good enough summary for the REST interface. )

This is one of the materials that I'm going to heavily rely on for my OpenResty talk at D2 forum ( http://d2forum.cn ) scheduled the next Sunday. So feedbacks (either positive or negative or just nit picking) will be highly appreciated ;)

Now I'm working on the GettingStarted tutorial for JavaScript programmers, Perl programmers, and Telnet users. Stay tuned!

I'm going to talk about OpenResty and pure JavaScript web applications in the "D2 Forum" conference which will be held on 27 of this month:

   http://d2forum.cn

(Two Yahoo US colleagues will give presentations there as well :))

I'd like to see the RSS feed and custom Action support landed onto OpenResty before this event. Let's wait and see :)