Deprecate HTTP and Websocket Support

[tidwall]

For security reasons (#89) I believe that support for HTTP and Websockets should be deprecated. We won't completely remove support, but Tile38 will require a flag at start up such as:

$ tile38-server --enable-http-transport

reference #89 #90

[tidwall]

This should target 2.0 release so we don't break 1.0. Until then, perhaps we should add the --disable-http-transport for 1.0.

[tidwall]

Perhaps --http-transport is a better name for the flag. Just a Boolean. It's true by default, at least for version 1.X.

[m1ome]

I will do this for 1.* and we can port this to 2.0 when time comes, just switching condition and flag name.

[tidwall]

@m1ome thanks for helping with this.

[m1ome]

@tidwall you are welcome!

[tercerapersona]

if websockets is deprecated, how should we use a Redis client to persist a connection and receive new messages from realtime geofence commands? as far as I know, all clients can send raw RESP commands, but they usually returns response "OK", will you include examples for node_redis or redis-py in the wiki?

[tercerapersona]

Ok, seems like a solution would be to use tile38's SETHOOK command, and for example set a redis endpoint which will receive messages in a PubSub queue. Then it would be possible to subscribe to that queue.

From a webapp perspective, wouldn't this dance add some overhead or performance issues?

[Tile38 hooks <-> Websocket server (running redis pubsub)] <-> Websocket webclient

So, in order to show realtime nearby results for each webclient, it results in 1 Tile38 hook + 1 redis queue per-webclient.