Improve handler interface and documentation

This change simplifies a little more the sub protocols mechanism.
Aliases have been removed. The renaming of loop handlers as long
polling handlers has been reverted.

Plain HTTP handlers now simply do their work in the init/2
callback. There is no specific code for them.

Loop handlers now follow the same return value as Websocket,
they use ok to continue and shutdown to stop.

Terminate reasons for all handler types have been documented.
The terminate callback is now appropriately called in all cases
(or should be).

Behaviors for all handler types have been moved in the module
that implement them. This means that cowboy_handler replaces
the cowboy_http_handler behavior, and similarly cowboy_loop
replaces cowboy_loop_handler, cowboy_websocket replaces
cowboy_websocket_handler. Finally cowboy_rest now has the
start of a behavior in it and will have the full list of
optional callbacks defined once Erlang 18.0 gets released.

The guide has been reorganized and should be easier to follow.

1 files changed, 0 insertions, 61 deletions

diff --git a/doc/src/guide/upgrade_protocol.ezdoc b/doc/src/guide/upgrade_protocol.ezdoc
deleted file mode 100644
index ad2d25a..0000000
--- a/doc/src/guide/upgrade_protocol.ezdoc
+++ /dev/null
@@ -1,61 +0,0 @@
-::: Protocol upgrades
-
-Cowboy features many different handlers, each for different purposes.
-All handlers have a common entry point: the `init/2` function.
-This function returns the name of the protocol that will be
-used for processing the request, along with various options.
-
-Cowboy defines four built-in handler types. Three of them are
-implemented as sub protocols. More can be implemented by
-writing a custom sub protocol.
-
-The following table lists the built-in handler types.
-
-||	Alias			Module				Description
-|
-|	http			-					Plain HTTP handler
-|	long_polling	cowboy_long_polling	Long-polling handler
-|	rest			cowboy_rest			REST handler
-|	ws				cowboy_websocket	Websocket handler
-
-Both the alias or the module name can be used to specify the
-kind of handler. In addition, a user-defined module name can
-be used.
-
-``` erlang
-init(Req, Opts) ->
-	{my_protocol, Req, Opts}.
-```
-
-The `init/2` function can also return some extra options for
-handlers that are meant to be long running, for example the
-`long_polling` and `ws` handler types. These options can also
-be passed on to custom sub protocols. For example the following
-`init/2` function defines both a timeout value and enables
-process hibernation:
-
-``` erlang
-init(Req, Opts) ->
-	{my_protocol, Req, Opts, 5000, hibernate}.
-```
-
-It is up to the sub protocol to implement these (or reject
-them if they are not supported).
-
-The `cowboy_sub_protocol` behavior only requires one callback,
-`upgrade/6`. It receives the Req object, the middleware environment,
-the handler and options for this request, and the timeout and
-hibernate values. The default timeout value is `infinity` and
-the default hibernate value is `run`.
-
-``` erlang
-upgrade(Req, Env, Handler, HandlerOpts, Timeout, Hibernate) ->
-    %% ...
-```
-
-This callback is expected to behave like a middleware. Please
-see the corresponding chapter for more information.
-
-Sub protocols are expected to call the `cowboy_handler:terminate/5`
-function when they terminate. This function will make sure that
-the optional `terminate/3` callback will be called, if present.