Change to Continuation format

[gerardtoconnor]

As discussed, PR is using existing async format (not Task), and is just updating Httphandlers to double parameter format that includes continuation.

[dustinmoris]

Thanks for this PR. You've put a lot of work into this project already and just want to say thanks for that! This is a great improvement. I changed the base to develop and I might think about some naming before releasing this, but I am planning to create a new release with this change in the next couple days!

I was thinking perhaps we keep calling the HttpCont a HttpHandler (what it was originally) and then type HttpPipeline = HttpHandler -> HttpHandler (or something to that effect). What do you think?

[gerardtoconnor]

If you wanna use that name format no problem, was just trying to avoid confusion (keeping HttpHandler as the composable fn), although on the composable handler, perhaps we use 'HttpPipe' as pipeline describes line of pipes, such that we can describe a web app as a handler pipeline? (Doesn't make much difference but to me pipeline always makes me think of the entire composed pipeline).

[dustinmoris]

Yeah I hear what you say... agree with you that pipeline is the entire thing put together. I will think a bit more about different names and if you have any suggestions please let me know. I just want to make sure that we pick some names that will make it easier for developers to talk about when discussing a Giraffe web application architecture, etc.

[gerardtoconnor]

Yeah fully agree, names have to be clear so there is no confusion discussing application architecture. Would it be worth ccing a few other main users/contributors to chime in on naming convention, so we cover all bases?

[dustinmoris]

sure! @slang25 @JonCanning @xdaDaveShaw @nicolocodev @Neftedollar @toburger @GraanJonlo @diegobfernandez @dsincl12

I cc'd everyone who was listed as a contributor under this project so far. Everyone welcome to chime in!

[dustinmoris]

I'll throw in a few words for brainstorming: pipe, pipeline, handler, bond, circuit, chain, link, belt, flow, ...

[dustinmoris]

@gerardtoconnor What do you think of this:

type HttpActionResult = Async<HttpContext option>
type HttpAction       = HttpContext -> HttpActionResult
type HttpHandler      = HttpAction -> HttpAction

EDIT:
One thing which I noticed is when I was searching for "HttpCont" to find all usages it brings up a lot of results because of "HttpContext". With HttpAction, HttpContext and HttpHandler the names are distinctive enough and I think its easy to reason about an architecture using these terms, but I'd be interested in your and other opinions if people care :).

[gerardtoconnor]

Good point on the names being too similar/subset, needs to be clearly different to avoid confusion.

On the HttpAction naming, might that cause confusion with c# parameterless lambda? I think HttpAction might confuse some people?

If we are sticking with HttpHander for the composable part, we just need to figure out type name of continuation? Potential Alt names could be:

HttpNext
HttpPipe
HttpFunc

[dustinmoris]

Hi, I've renamed it to HttpAction yesterday (was working on it before you posted your suggestions) and I have checked that in for now, but just want to say that it doesn't mean I am settled on it yet.

I thought of HttpAction, because even though C# has an Action, they still named the MVC methods inside a Controller an "Action" as well, so I thought a HttpAction could make sense in Giraffe's context. I also like HttpFunc, but there's a Func in C# as well (Action with return type) and I thought when speaking to someone then HttpAction sounds more rounded than HttpFunc?

[gerardtoconnor]

I was suggesting Func only due to it making more sense than Action if you are drawing a comparison to c# lambdas, as Func is a delegate that accepts parameters (`HttpContext1 here). The use of "Action" in MVC never made much sense to me as it confuses the lambda language and as action is usually a command/instruction in isolation of an input, to me it does not make sense as a name for a continuation function, but that being said, if everyone else thinks it's naturally fitting, I have no problem going with it as there are other things to work on and we shouldn't get too bogged down in naming.

How do you feel on HttpPipe ? It is nicely distinct, fits in with pipeline language, only small shortfall being that it is not the descriptively the best choice for a continuation function.

Fine with leaving as is for now if you prefer, I'd rather focus on Task CE, than worrying too much about the name.

[dustinmoris]

I think pipe is too abstract. I can settle on HttpFunc if you're happy with it too :)

[gerardtoconnor]

Sure we can leave as is for now and see if anyone else proposes any new ideas, Quick to change later once we have a broader consensus back. Have you managed to migrate any projects testing the new format? Once you're happy with the continuation PR, I can resubmit Task CE based off this branch, using improved binding (through extension methods) that remove the requirement of type assertions on bindings.

…

On 31 July 2017 at 16:22, Dustin Moris Gorski ***@***.***> wrote: I think pipe is too abstract. I think I could settle on HttpFunc if you're happy with it too :) — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#71 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AFI6vzsdPJbxNcw6ni6SoDJoGzVAGhiyks5sTfFCgaJpZM4OnYjA> .