As a result, it is no longer possible to chain promises
(then().then().then(etc.)), but that is actually not an issue for Isso.
The deferred/promise implementation is roughly based on
http://stackoverflow.com/a/17722683 and stackp/promisejs.
When using Gunicorn or uWSGI to run `isso.dispatch` it would
automatically initialize and a default Isso instance (and cause
several logging messages), although never used.
If you use uWSGI or Gunicorn, you have to change the module from
`isso` to `isso.run`.
The previous approach using a custom X-Custom header did work for the
client-side, but not for activation and deletion links. Now, you need
to add a `name = foo` option to the general section. `isso.dispatch`
then binds this configuration to /foo and can distinguish all API
calls without a special HTTP header.
Also add an option `direct-reply` to control the number of comments
on a thread without referencing a child (to avoid a simple while loop
that `curl -XPOST ...` the url).
Defaults to 3, that means a /24 (or /48 for IPv6) address can only post
3 direct responses on a thread at all.
Keep Isso modular, not monolithic. Make it easy to integrate a
web interface or add XMPP notifications.
This refactorization includes minor bugfixes and changes:
* CORS middleware did not work properly due to wrong unit tests
* more type checks on JSON input
* new detection for origin and public url, closes#28
* new activation and delete url (no redirect for old urls, but you can
convert the old urls: copy hash after `/activate/` (or delete) and
open `/id/<id of comment>/activate/<hash>`
* move crypto.py to utils/
With this commit, SMTP is no longer automatically configured: add
`notify = smtp` to the `[general]` section to use SMTP.
Martin Zimmermann