[PSR-15] Pipeline Pattern and Middelware Pattern

[Tomasz Darmetko]

Hello,

From HTTP Server Middleware Meta Document:

The design pattern used by middleware has existed for many years as the pipeline pattern, or more specifically, "linear pipeline processing".

I'm trying to understand how does the pipeline pattern fits into proposed concept of middleware and I'm failing to see the connection. The link to Wikipedia states:

In computing, a pipeline is a set of data processing elements connected in series, where the output of one element is the input of the next one.

But this is not what proposed middlewares are doing. If one middleware takes an request as input and output an response then the response can not be inputted into a next middleware, because of the type mismatch. Am I right?

 The concept of linear pipeline processing is even more fuzzy to me. According to the Wikipedia:

A linear pipeline processor is a series of processing stages and memory access.

To me it seems to be completely out of context of the proposed middleware standard recommendation and doesn't provide any reference to the source literature.

 Another page in the Wikipedia about pipelines in software engineering seems to be more illuminating:

Narrowly speaking, a pipeline is linear and one-directional, though sometimes the term is applied to more general flows. For example, a primarily one-directional pipeline may have some communication in the other direction, known as a return channel or backchannel, as in the lexer hack, or a pipeline may be fully bi-directional. Flows with one-directional tree and directed acyclic graph topologies behave similarly to (linear) pipelines – the lack of cycles makes them simple – and thus may be loosely referred to as "pipelines".

Although I still fail to see how middlewares can be arranged in pipeline (input - output type conflict I mentioned) and why they are linear.

To sum up - the statement at the beginning of the HTTP Server Middleware Meta Document is in my opinion more confusing than illuminating.

I propose to remove it or elaborate on it more, preferably with links to the source literature or at least to the second Wikipedia page that I mentioned.

Thank you for your comments in advance :) !

[Woody Gilk]

On Thu, Mar 23, 2017 at 4:28 PM, Tomasz Darmetko <isi...@gmail.com> wrote:

I'm trying to understand how does the pipeline pattern fits into proposed concept of middleware and I'm failing to see the connection.

That's probably fair. At some point in the past I had a diagram that helped illustrate what the intention of this sentence meant. 

Do you know of a pattern that applies to how middleware operates?

--
Woody Gilk
http://about.me/shadowhand

[Woody Gilk]

On Thu, Mar 23, 2017 at 4:28 PM, Tomasz Darmetko <isi...@gmail.com> wrote:

I propose to remove it or elaborate on it more, preferably with links to the source literature or at least to the second Wikipedia page that I mentioned.

https://github.com/php-fig/fig-standards/pull/903/files

[Tomasz Darmetko]

The best illustration of a middlewares arrangement I can find is this one, from the article Working with Slim Middleware. Maybe we should include such an illustration in the Meta Document? One picture is worth many words. We could ask the author to make the illustration available on CC license. Eventually even I could try to create one on CC license.

[Rivera, John]

I think the current middleware proposal is conceptually very close to continuations (https://en.wikipedia.org/wiki/Continuation).

--
You received this message because you are subscribed to the Google Groups "PHP Framework Interoperability Group" group.
To unsubscribe from this group and stop receiving emails from it, send an email to php-fig+u...@googlegroups.com.
To post to this group, send email to php...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/php-fig/c1c7408c-4792-4115-a371-cd305cda128d%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Woody Gilk]

I reached out to StackPHP to see if we could reuse their image, which more simple but essentially the same http://stackphp.com/img/onion.png

--
Woody Gilk
http://about.me/shadowhand

--

You received this message because you are subscribed to the Google Groups "PHP Framework Interoperability Group" group.

To unsubscribe from this group and stop receiving emails from it, send an email to php-fig+unsubscribe@googlegroups.com.

[Tomasz Darmetko]

The picture from StackPHP is missing the third case from 5.1 Middleware Design section:

The middleware may: (...) Create and return a response without passing it to the delegate, thereby preventing any further middleware from processing.

BTW - the wording there is also imprecise - middleware can not pass a response to the delegate. I will make a pull request for that.

On Friday, March 24, 2017 at 4:56:23 PM UTC+1, Woody Gilk wrote:

I reached out to StackPHP to see if we could reuse their image, which more simple but essentially the same http://stackphp.com/img/onion.png

--
Woody Gilk
http://about.me/shadowhand

On Thu, Mar 23, 2017 at 5:21 PM, Tomasz Darmetko <isi...@gmail.com> wrote:

The best illustration of a middlewares arrangement I can find is this one, from the article Working with Slim Middleware. Maybe we should include such an illustration in the Meta Document? One picture is worth many words. We could ask the author to make the illustration available on CC license. Eventually even I could try to create one on CC license.


On Thursday, March 23, 2017 at 10:48:55 PM UTC+1, Woody Gilk wrote:

On Thu, Mar 23, 2017 at 4:28 PM, Tomasz Darmetko <isi...@gmail.com> wrote:

I'm trying to understand how does the pipeline pattern fits into proposed concept of middleware and I'm failing to see the connection.

That's probably fair. At some point in the past I had a diagram that helped illustrate what the intention of this sentence meant. 

Do you know of a pattern that applies to how middleware operates?

--
Woody Gilk
http://about.me/shadowhand

--
You received this message because you are subscribed to the Google Groups "PHP Framework Interoperability Group" group.

To unsubscribe from this group and stop receiving emails from it, send an email to php-fig+u...@googlegroups.com.

[Michael Mayer]

On Friday, March 24, 2017 at 4:38:34 PM UTC+1, Rivera, John wrote:

I think the current middleware proposal is conceptually very close to continuations (https://en.wikipedia.org/wiki/Continuation).

While this is true for almost all middlewares I'm aware of this is not true for the current proposal.

The issue is that continuations are invoked/called (e.g. call/cc) and Continuation-passing style is a functional programming style. Unfortunately, Woody and others want to design Middlewares without `__invoke` interfaces by all means; thus we have:

interface DelegateInterface
{
    /**
     * Dispatch the next available middleware and return the response.
     *
     * @param ServerRequestInterface $request
     *
     * @return ResponseInterface
     */
    public function process(ServerRequestInterface $request);
}

Hence, the `$delegate->process($request)` means (see Why the term "delegate"?):

the delegate processes the request for the original middleware in order to return a response.

Therefore, they are conceptually distinct for ideological reasons.