I'm planning to leave non-EventSource "/get" in until after 0.6.0, then
remove it. I think it's cleaner for the logs to have the two
forms (EventSource and immediate) use different URLs.
This removes the 'allocations' table entirely, and cleans up the way we
prune old messages. This should make it easier to summarize each
connection (for usage stats) when it gets deallocated, as well as making
pruning more reliable.
Without this, old senders will throw a messy 404 traceback when talking
to a modern server.
Unfortunately 0.4.0 receivers don't make API calls in the right order,
so they throw a 404 before seeing our "you need to upgrade" message.
I was really confused about the Server-Sent Events syntax. This new one
is compatible with actual web browsers and the spec:
http://www.w3.org/TR/eventsource/
This requires a DB delete/recreate when upgrading. It changes the server
protocol, and app IDs, so clients cannot interoperate with each other
across this change, nor with the server. Flag day for everyone!
Now apps do not share channel IDs, so a lot of usage of app1 will not
cause the wormhole codes for app2 to get longer.
This removes "side" and "msgnum" from the URLs, and puts them in a JSON
request body instead. The server now maintains a simple set of messages
for each channel-id, and isn't responsible for removing duplicates.
The client now fetches all messages, and just ignores everything it sent
itself. This removes the "reflection attack".
Deallocate now returns JSON, for consistency. DB and API use "phase" and
"body" instead of msgnum/message.
This changes the DB schema, so delete the DB before upgrading the server.
The "bytes % bytes" syntax only appeared on py3.5, so don't use it.
Updated travis to expect py3.4 works.
The twisted side is probably even more broken for py3.4 than it is for
py3.5.
The twisted.python.logfile in Twisted-15.4.0 is not yet compatible with
py3, but can be bypassed by not daemonizing the server (so it doesn't
write to a logfile). This has been fixed in twisted trunk, so when
15.4.1 or 15.5.0 comes out, this will no longer be needed. But I think
we'll leave it in place, since sometimes it's handy to run a server
without daemonization.
Now the server allocates a channel randomly from set of available ids
with the shortest possible length. So concurrency=1 will always yield a
channel-id between 1 and 9 (inclusive). If we have 9 simultaneous
sessions, we'll start allocating channels from 10 to 99. 100
simultaneous connections kicks us into the 100-999 bucket, etc.
