An experimental webserver based off tulip (pep-3156)
Project description
Archangel is a webserver designed to be fast and easy to use for personal usage. It was created to replace an internal webserver based off of flup for fcgi and wsgiref for http serving (basically anything would be an improvement) as well as explore the new pep-3156/Tulip based library by Guido van Rossum
Archangel is designed to be ‘fast’. This does not mean however that archangel is fast, Archangel is instead intended to explore how fast a server using an event loop based of tulip can be made to go and what is needed to get it there.
As an additional side effect it should serve as a light house in the fog as to what you should or should not do with Tulip (Of course it is still yet to be determine on which side of the divide Archangel ends up)
Tenets:
- Only do things when we need to:
Do things “Just in Time”
- Only do things we have to:
Be lazy
- Do it quickly:
Go back to sleep as fast as possible
What Archangel provides
Pre-forking Webserver
WSGI connector
The ability to run multiple dissimilar WSGI apps in the same process and route requests to them individually based off of PATH_INFO or HOST headers
What Archangel does not provide
‘Cron’ like functionality, this is now implemented via Tulip. get a copy of the mainloop with loop = tulip.get_event_loop(), then attach your cron function with loop.call_repeatably(15.0, my_cron) which will call your my_cron function every 15 seconds
Unix Signal support, this functionality is already provided by Tulip via the add_signal_handler functionality
Long running background tasks. Tulip can be used to launch background contexts via call_soon. note that CPU bound tasks should yield periodically to prevent blocking of other tasks or use run_in_executor provided by the main loop.
Possible Future Features
Internal ‘signalling’ allowing applications to signal each other and respond accordingly
Compatibility Notes
For performance, any 3rd party library you use will need to be tulip/pep-3156 compatible and return a future on blocking calls so that it may be yield from’d. libraries using open() and socket.socket or other blocking calls will still work without issue but will prevent other requests from being handled while the system call is blocked
To use traditional style locks and events, use the implementations in tulip rather than the threading library
TWIG: Tulipe Webservices Gateway Interface
Archangel provides a test-bed for developing a new protocol loosely based off of pep-3333/WSGI, Designed for use with Tulip and providing a more ‘stream’ like interface. This can be used to implement long polling clients as well as support traditional WSGI like request/response through the use of middleware that will be bundled with Archangel.
An inital draft of the TWIG spec can be found here
Requirements
Python 3.3 or greater
Distutils2 (to replace setup.py, a fallback is provided)
A copy of the Tulip library
PyYaml for parsing the config files
Getting the Latest version
The latest version of Archangel can be obtained with mercurial/hg using the following command:
hg clone http://code.pocketnix.org/archangel
Links
Change Log
0.3
Added twig module
Added Request object
Added Response object
Expand on TWIG PEP
0.2.1
Minor bump to update filenames (WSGI-STREAM => TWIG)
0.2: Fresh Breeze
Split code into modules
Name changes to WSGIProtocol and friends, now split along ‘FCGI’ and ‘HTTP’ lines
Framework can make requests with to a special function using a ‘looks like wsgi if you squint hard enough’ protocol
0.1.2
Added WSGI-STREAM spec
Refined documentation and links
Added Changelog
0.1.1
Inital code
README file
Download files
Download the file for your platform. If you're not sure which to choose, learn more about installing packages.
