Get rid of annoying inconsistencies between Lwt and Async

[rgrinberg]

As we've said before, async and lwt backends should follow the conventions of async and lwt but in some cases we have some pointless differences. For example:

• Different orders of optional arguments is it ?headers ?flush or ?flush ?headers?
• respond_string vs. respond_with_string (I prefer the former)
• In some calls the status code is optional, in others it's mandatory
• Body.map in the lwt backend should take f first without a label.
• Differences in how some modules are packed. Cohttp_lwt_body vs. Cohttp_async.Body (I don't have a preference)

I'm sure there's more - this is just after a quick glance.

I know we've ruled against #119 but how about resurrecting an lwt/async agnostic signatures for these functions and simply using them for type checking. While still expanding all of the aliases to have decent docs.

[avsm]

That's a good idea...I'd be very much in favour of using those signatures to "consistency check" the backends.

On 8 Nov 2014, at 22:35, Rudi Grinberg [email protected] wrote:

I know we've ruled against #119 https://github.com/mirage/ocaml-cohttp/pull/119 but how about resurrecting an lwt/async agnostic signatures for these functions and simply using them for type checking. While still expanding all of the aliases to have decent docs.

[avsm]

Did the change to Body, but not sure it isn't just bikeshedding -- the Async backend is still different.

[rgrinberg]

Yeah that's probably the least important change. Imo the naming of things is what's really ugly now. Unfortunately, cohttp has quite a few downstream users for a "beta" library. I suppose we can keep always keep aliases for the old stuff.

What about the deal with labelled arguments in the lwt server api. E.g. it takes unit as a last parameter in every call while Async has the last parameter non labelled? The former is much more consistent, while the latter is "prettier".

[neojski]

See also: Lack of post_form in async: #235.