[Web-SIG] ANN: General availability of the WebCore WSGI nanoframework v2.0.

[Alice Bevan–McGregor]

> Best Practices Morpheus says: "What if I told you things can get 
simpler, more independent, and more testable, with a separation of 
concerns in a glorious holy land?"

WebCore is a WSGI nanoframework, a fraction of the size of competing 
“microframeworks”, and culmination of more than ten years of web 
development experience. It provides a clean API for standard points of 
extension while strongly encouraging model, view, controller 
separation. Being less than 400 source lines of code (SLoC of 
`web.core`; excludes comments and documentation) and containing more 
comments and lines of documentation than lines of code, WebCore is 
built to be insanely easy to test, adapt, and use, allowing any 
developer familiar with programming (not just Python programming) to be 
able to read and understand the entirety of the framework in an evening.

* Pypi Package: http://s.webcore.io/fjYp
* Annotated Source Documentation: http://s.webcore.io/fja7
* Source Repository: http://s.webcore.io/fjVF
* Compatible with: Python 2.7+, Python 3.2+, Pypy, Pypy3
* Dependencies: WebOb, marrow.package
* 100% test coverage.
* Digitally signed release artifacts and commits.

WebCore adds a light-weight dependency-graphed extension layer to WSGI, 
offering points of extension which replace WSGI middleware, as well as 
callbacks difficult to implement in bare WSGI, while also supporting 
standard WSGI middleware both as an application and when treating 
WebCore as middleware itself. As the #1 thing a typical framework is 
responsible for is to resolve a URL to a controller to handle the 
request, this process has been standardized under a "dispatch protocol" 
(http://s.webcore.io/fjRy) which WebCore speaks. The Marrow Open Source 
Collective provide several framework-agnostic reference implementations 
covering regular expression-based routes, object dispatch (attribute 
descent), and traversal (mapping descent), as well as more abstract 
"meta-dispatchers" and "dispatch middleware".

	from web.core import Application
	Application("Hi.").serve('wsgiref')

The rest is up to you, the developer. WebCore is as opinionated as a 
coma patient.

A request comes in, hits the WebCore WSGI Application or outermost WSGI 
middleware layer, dispatch resolves an "endpoint", the endpoint is 
executed if callable, and the return value (or endpoint if not 
callable) is used to find a view which populates the response. The 
example above relies on the fact that there is a default view to handle 
strings.

Namespaces, virtual dependencies (extras_require) and standard Python 
entry_points plugin registration are extensively utilized by the 
framework. You may place your own packages within the `web`, `web.app`, 
`web.ext`, `web.server`, etc. namespaces if desired. WebCore is also 
"optimization aware" and will eliminate several expensive validation 
tests and all debug-level logging from production environments when run 
with -O or with PYTHONOPTIMIZE set. WebCore was designed to make use of 
under-utilized WSGI features such as chunked streaming responses and 
thus pairs naturally with the template engine "cinje" 
(http://s.webcore.io/fjUx) allowing for the ultimate in responsiveness. 
Where Django gets 2 generations per second on a 1000 row table test, 
cinje gets nearly 40,000; see the cinje wiki. Eliminate boilerplate and 
enjoy a snappier app today!

Please give WebCore (and cinje!) a try on your next project or 
experiment; see the README, many examples, and extensively documented 
source code to learn more. You may be pleasantly surprised to discover 
you won't miss those monolithic framework features you weren't using. 
Join us in #webcore on Freenode IRC if you have any questions or 
comments; we'd love to hear from you and will gladly assist users 
getting started using the framework or evaluating and integrating 
components.

Proudly developed in Montréal with the support of Illico Hodes 
(http://s.webcore.io/fjYI).