archangel 0.3

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

• Design Notes

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