From c5a9771ac4f7844b61b5e36bfc7eb371a082c560 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Lo=C3=AFc=20Hoguin?= Date: Mon, 2 Jan 2017 19:42:47 +0100 Subject: Remove ROADMAP file The only ROADMAP now is small fixes toward making it stable and very little interface changes, so the file is not that useful anymore. --- ROADMAP.md | 112 ------------------------------------------------------------- 1 file changed, 112 deletions(-) delete mode 100644 ROADMAP.md diff --git a/ROADMAP.md b/ROADMAP.md deleted file mode 100644 index 530f6a0..0000000 --- a/ROADMAP.md +++ /dev/null @@ -1,112 +0,0 @@ -ROADMAP -======= - -This document explains in as much details as possible the -list of planned changes and work to be done on the Cowboy -server. It is intended to be exhaustive but some elements -might still be missing. - -2.0 (R17 and R18) ------------------ - -The main features that will be added to Cowboy 2.0 are support -for HTTP/2.0 and Websocket permessage deflate compression. - -A complete analysis of the httpbis set of specifications -will be performed and extensive tests will be written to -ensure maximum compatibility. - -A number of backward incompatible changes are planned. These -changes are individually small, but together should result -in a large improvement in usability. - -### New cowboy_req function - -A convenience function will be added to more easily process -HTML forms that were sent using POST. These forms have two -main ways of being submitted: as a form urlencoded format, -or as multipart. The latter case may also be used to submit -files, therefore we also need a way to handle this. We also -need to take into account that we are reading from the socket -and can't take as much a shortcut as with `match_qs/2`. - -The function will work similarly to other body reading functions, -in that it may require more than one call to obtain everything. -In this case there would be two return values: the `ok` return -with the map filled with key/value pairs, ending the body reading; -and the `file` return that informs the caller that a file has been -provided and the caller must handle it. If the caller calls the -function again without doing anything, the part is just skipped, -like what `part/1` is doing. If a file is the last input from -the form then a subsequent call will return an `ok` return with -an empty map. - -The interface would look as follow: - -``` -match_body(Fields, Req) -> match_body(Fields, Req, []) -match_body(Fields, Req, Opts) - -> {ok, Map, Req} - | {file, FieldName, Filename, CType, CTransferEncoding, Map, Req} - when Req::req() -``` - -It would be up to the caller to decide what to do with the -maps returned. Fields are in order so the map returned may -be empty if the form starts with a file, or may only -contain the values before the file input if this one is -in the middle of the form. It is of course possible to -merge all maps returned into one though that should not -be needed very often. - -It is also possible to switch from this function to only -multipart functions if the function returns a `file` tuple, -as this function is a higher level interface that simply -calls the multipart functions when the request body is -in multipart format. - -### Hooks - -The interface of the `onresponse` hook will change. There has -been a number of issues and added complexity with the current -interface that warrant fixing. The main problem is that the -hook may be used to change the reply, by calling the reply -function again, forcing us to be careful not to reprocess -everything again. - -To fix that, we will cut the reply mechanism in two steps, -one that is basically some preprocessing of the response -header to follow the protocol requirements, and then the -actual response. The `onresponse` hook will fit in the -middle, being called from the first step and calling the -second step itself. - -If a body streaming function is provided, the hook will -also receive it (unlike today). It will not be able to -inspect its contents however. - -This should greatly simplify the code and allow users to -do any operation they wish. - -### Low-level interface documented - -A special chapter of the manual will document a low-level -interface that may be used in middlewares or hooks (but -nowhere else). This includes the Req access and update -functions and the new response function described above. - -### Loop - -We probably want to send something other than 500 when the -max data read value has been reached. This happens when the -client is misbehaving and is not a server error, but rather -a safeguard. - -### REST - -The documentation for all REST callbacks will be updated -to describe whether they can have side effects. This will -allows us to build introspection tools on top of a working -REST API. - -Range support will be added. -- cgit v1.2.3