This is a python web server using the wonderfull libev (http://software.schmorp.de/pkg/libev.html) library. Thus this is yet an another asynchronous web server like Medusa, Twisted, Apricot. And Fapws is a WSGI compliant web server.
Fapws1, Fapws2 and Fapws3 are "internal" project's name. The rename correspond to a full re-write.
In the begining I made Fapws1, a Python extension based on the Apricot code. Then, quickly comes the need to have much more features in it, and I've called it Fapws2. Fapws1 has never been published. Fapws2 is rebuild based on the http library of libevent. Works great, but I've been forced to modify the evhttp_handle_request. Despite seevral mails to the libevent mailing list, no one was agreed to accept my patch to the http code of libevent. Thus, or use use it with libevent <1.3e or you must change the code of libevent before using it for Fapws. This is not a so good way of working ;-(. Than comes Fapws3, a rebuild of Fapws2 without dependencies to http's API of libevent. At that moment Marc Lehmann posts, in the libevent mailinglist, a mail describing the creation of a "new" and optimized event's library similar to libevent. Because the code was much more clean to me and because the documentation provided (http://pod.tst.eu/http://cvs.schmorp.de/libev/ev.pod) was very clear, I've decided to give it a try.
Support for Fapws2 will be strictly limited to bug fixing. My current work will be focused on Fapws3.
In that case, the usual question is why an new one ? In short, the answer is because it sounds that Apricot is not more maintained, and because Medusa and Twisted can not go as fast as Apricot. Indeed, after several pure performance tests it appears that, thanks to the libevent library used in Apricot, is the fastest python web server.
But that not the only reason. Personnally, I prefer event's web server. Indeed, such architecture gives more performant web server and with a much more limited memory foot print. You can easly install them a memory limited machines (like VDS for example).
Fapws must stay the most simple web server and the fastest. Thus the core of the application is quite limited. Every additional feature will be placed inside a "contrib" sub-directory. This is valontary for disk space "foot print" reasons. Thus Fapws must also facilitate the disk utilisation.
Please read the INSTALL document provided.
Using Fapws is quite simple and must be done in 4 major steps:
- You define the main parameters of your webserve with the method "start" and the method "base". Unless you really know what you are doing, I strongly suggest to use the "base" module provided within the package.
- You define you WSGI python callbacks.
- You link the URL patht he the python callbacks previously created.
- You start you webserver by triggering the "run" method.
- As describbed in the Libev documentation, you can controle the Event Loop used. By default Libev estimate what's the best one for your architecture, but you can overwrite this selection by using the environment variable: LIBEV_FLAGS. Choices are: 1=select, 2=poll (everywhere except windows), 4=epoll (Linux), 8=kqueue (BSD clones), 16=devpoll (solaris 8), 32=port (solaris 10)
For you help, check the samples.
You will find information concerning Fapws on my own blog: http://william-os4y.livejournal.com/
Theoritically anywhere where both Python and Libev are running.
Have fun with Fapws.
William