- if a description follows a summary, the summary is used as a title and the
lines of description form a body.
- if a description occurs without a preceding summary, it's first line is used
as a title, and the remainder are used as a body.
- Add Streaming endpoint to the comprehensive API.
- Rename BuildFromStream to FromResultStram
- I'm tempted to rename everything in the Servant.API.Stream
(add some prefixes, `header` is too good name to steal)
The TODO in `servant-docs` is left intentionally.
- WIP: pending http-api-data release
- TODO: remove MIN_VERSION_http_types
- There have been 3 major releases of http-types:
- 0.10 change name of variable
- 0.11 lowercase escaped URIs
- 0.12 uppercase escaped URIs
- It's easier for us to support only latest, migration from 0.9/0.10 to 0.12
is trivial for the downstream. 0.11 may cause semantic (non-type-error) breakage somewhere.
Also allow lens-4.16, remove MIN_VERSION_http_types conditionals, and
update `stack.yaml`
Changes Header, ReqBody and QueryParam to take a modifier list.
Resolves https://github.com/haskell-servant/servant/issues/856
ResponseHeader story turns to be somewhat ugly, but it can be made
elegant when https://github.com/haskell-servant/servant/issues/841 is
implemnted, then we can omit HList aka Header Heterogenous List
implementation.
- servant-server changes:
Writing server side intepretations is quite simple using
`unfoldRequestArgument`, which makes Header and QueryParam look quite
the same.
`ReqBody` cannot be easily made optional with current design (what that
would mean: No Content-Type Header?), so that dimensions isn't used
there.
- Add HasLink for all the rest ComprehensiveAPI combinators
- Add 'tricky' Header', QueryParam' endpoints to ComprehensiveAPI
- servant-docs: Quick'n'dirty implementation. Don't use modifiers information (yet).
The changelog for `servant` contains changes across core packages,
as we release them as a suite.
Also added links to the GitHub master as we might update entries
for old versions, as changelogs are written by humans.
- Add build-tool-depends, so new-build can use hspec-discover
- Add mtl bounds in tutorial (and dependency on mtl-compact)
- Add extra-source-files to tutorial, so it's buildable from sdist
For some reason, 2nd-level headings are used for introductions and for
each API endpoint, but then it immediately jumps to 4th-level
headings.
Instead, promote everything that's 4th-level to 3rd-level.
This relies on the behaviour of pandoc, and as such may not apply to
other Markdown renderers.
Before this change, you would have something like:
> - Example: `application/json`
>
> ```javascript
> "HELLO, HASKELLER"
> ```
When converting this to HTML, PDF, etc. the code block is _not_
contained within the bullet point.
With this change, the generated markdown looks like:
> - Example: `application/json`
>
> ```javascript
> "HELLO, HASKELLER"
> ```
With pandoc at least, this effectively indents the entire code block
to be under the bullet point, which is the intended effect.
Note that the code itself is _not_ indented (which might break other
Markdown renderers) as to do so would require splitting on newlines,
which may have unintended consequences when dealing with generated
values (may contain `\r\n`, etc.).
