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
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
Download Files
Download the file for your platform. If you're not sure which to choose, learn more about installing packages.
