Re: Minimal HTTP middleware

[Michael Mayer]

For clarification: I'm still undecided about the usefulness of the two 
modifier interfaces (described in this thread as "$request = $foo
->modify($request);" and "$response = $foo->modify($response);"). I've 
added them to the hms proposal 

 to 
make them discussable and to explore their pros and cons. As Rasmus 
suggested, they will be removed within the next few days because the 
ActionInterface/HandlerInterface can stand on its on.

On Saturday, May 20, 2017 at 10:33:33 PM UTC+2, Matthieu Napoli wrote: 

> Rasmus:
>
> I can see the handler-interface having 3 uses in the context of PSR-15:
>> …
>> 3. As type-hint for the "final" handler supported by many dispatchers.
>
> 3. I agree this is a bit of an ugly detail and it would be better if we 
> could do without, but honestly this is just a detail, and it works, and 
> it's not really a practical problem, I don't see how a PSR would matter here
>

That PSR would also allow interop of routers, controllers and final 
handlers, and indeed solve practical problems, e.g. if you use it with your 
pipe function:

// diff in pseudo code:
- function pipe(MiddlewareOrHandler[] stack) : Middleware {}
+ function pipe(Middleware[] stack, Handler $final) : Handler {}
- function router(array routes) : Middleware {}
+ function router(array routes) : Handler {}

Thus you do not need to fabricate handlers like the one at your 
Router::dispatch 
,
 and 
the code of your example becomes bit more explicit:

$application = pipe([
ErrorHandlerMiddleware::class,
ForceHttpsMiddleware::class,
], prefix([
'/api/' => pipe([
HttpAuthenticationMiddleware::class,
], router([
'/api/articles' => /* controller */,
'/api/articles/{id}' => /* controller */,
])),

'/' => pipe([
MaintenanceModeMiddleware::class,
SessionMiddleware::class,
DebugBarMiddleware::class,
], router([
'/' => /* controller */,
'/article/{id}' => /* controller */,
])),
])); 

As you can see, there is no essential difference for the end user setup. 
Although, we do not need to create those meaningless $next delegates: the 
prefix and router functions return them.

And yes the router will be invoked with a $next, but IMO that's a good 
> thing: the router can call $next if the URL doesn't match any route 
> . 
> That allows, for example, to use several routers in a single pipe (e.g. if 
> you have modules).
>

I disagree, that's not a good thing, this means $next would be used 
differently by different middlewares:
For example for your HttpAuthenticationMiddleware, calling $next means: 
everything is fine; lets carry out the real task and if that fails I will 
try to handle that.
For the router you're suggesting, calling $next means: something went 
wrong; lets delegate the task to someone else and if that fails I do not 
care.

Thus, using $next to signal "404 Not Found" is bad for many reasons:
1. 404 is one error of many, e.g. what about routing related errors like 
"405 Method Not Allowed" and "415 Unsupported Media Type"?
2. What kind of *final handler* do I need to dispatch middlewares? For 
router middlewares I probably want a *NotFoundHandler*, but for a 
controller action I probably want a handler which returns a plain response 
object.
3. Because of 2., you need some conventions, i.e. framework specific 
conventions(!), which means it would neither be possible to reuse your 
'/api/' middleware stack across multiple frameworks nor and more 
importantly your RouteMiddleware itself.
 

> And by the way this is a bit what Slim and IIRC Zend Expressive do: route 
> handlers can be controllers or can be pipes, that's how you can add "route 
> middlewares" (I hope I'm not wrong here).
>

Slim controller actions 

 are 
not middlewares, they get an $args argument instead of a $next.
Zend Expressive and Zend Stratigility:

$app->pipe('/', function (ServerRequestInterface $request, DelegateInterface 
$delegate) {
return $delegate->process($request);
});

$app->pipe('/', function (ServerRequestInterface $request, DelegateInterface 
$delegate) {
$response = new Response();
$response->getBody()->write('Wtf?');
return $response;
});

Zend Expressive is based on Stratigility and returns a 404 for '/'. 
Interestingly, Zend Stratigility itself returns a 200 (content: 'Wtf?') – 
yes, exactly the same code snippet can be used in both frameworks.
IMO, these setups are hard to debug, and to me, it is another reason why I 
dislike routers/controllers which call $next: I can never be sure what 

Re: Minimal HTTP middleware

[Michael Mayer]

On Saturday, May 13, 2017 at 7:31:20 PM UTC+2, Woody Gilk wrote:

> My question is more about how the interfaces proposed by David would do 
> this delegation. Right now I don't see how it would be possible without 
> passing a factory to a middleware, which (I thought) he was attempting to 
> avoid.
>
> --
> Woody Gilk
> http://about.me/shadowhand
>

interface RequestHandlerInterface
{
public function dispatch(ServerRequestInterface $request) : 
ResponseInterface;
}


interface Middleware {
function dispatch(RequestHandlerInterface $next) : 
RequestHandlerInterface;
}


class ResetParsedBody implements Middleware {
function dispatch(RequestHandlerInterface $next) : 
RequestHandlerInterface
{
return new class($next) implements RequestHandlerInterface {
private $next;


public function __construct(RequestHandlerInterface $next)
{
$this->next = $next;
}


public function dispatch(ServerRequestInterface $request) : 
ResponseInterface
{
return $this->next->dispatch($request->withParsedBody(null
));
}
};
}
}

Would this answer your question?

-- 
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+unsubscr...@googlegroups.com.
To post to this group, send email to php-fig@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/php-fig/3f9f2e9a-6f67-4d3d-8a43-cf9f08cae679%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Controllers and Filters PSR(s) ?

[Michael Mayer]

(Sorry, for crossposting 
https://groups.google.com/forum/#!topic/php-fig/B3jtdJA7-6w)

Well, some work is already done:

   - Github Organisation: HTTP Message Strategies Interop 
   
   - pre-draft PSR HTTP Message Strategies 
   

   - Common interfaces for HTTP Message Strategies 
   
   - Some examples 
   

 are 
   also available, notably:
   - A fork of David Négrier's symfony-httpinterop-bridge 
  

   
Currently, the main difference, which is still up for discussion(!):

   - ServerAction:__invoke instead of Handler:handle
   
Some arguments for and against __invoke:

   - Pros, at the Meta Document 
   

   - Pros+Cons, at Issues 
   
   - Action vs. Handler at PR#5 
   

I know, Rasmus and I disagree on __invoke, but I'm willing to go with the 
majority. For this reason, I invite Rasmus as an organisation member and 
everybody else who is interested to participate.

Bests,
Michael

On Monday, April 24, 2017 at 4:47:35 PM UTC+2, Rivera, John wrote:
>
> Excellent points, and after reading your response, I concur. 
>
> John
>
> On Apr 24, 2017, at 10:35 AM, Rasmus Schultz  > wrote:
>
> John, 
>
> That point of view is extremely in-tune with my thinking.
>
> Hence that other thread I started this week-end, I don't know if you 
> looked at that?
>
> PSR-15, as-is, does require someone to implement a dispatcher - that 
> middleware-interface is no use on it's own. It is, as you say, pushing the 
> boundary into dictation, by, at least to some extend, mandating more than 
> is required for basic inter-op.
>
> I don't think the interfaces I'm proposing here do that?
>
> They're not dictating any implied architecture - they'd exist only to make 
> it possible to abstract very high-level operations and make them 
> interoperable.
>
> The handler-interface, for example, could be used as an entry-point for an 
> entire project, as a front-controller, as middleware (as discusssed in the 
> other thread) and probably has myriad other uses.
>
> Likewise, filtering a request or response is a very basic operation with 
> many uses.
>
> The point is, I don't have a single designated use for any of these three 
> interfaces - you have your complete architectural freedom, but when you do 
> have components where it's possible (and meaningful) to abstract from these 
> high-level operations, you can implement one (or more) of these interfaces.
>
> That helps with interoperability by allowing components to depend on other 
> components in the abstract - to depend on a very small facet, or a very 
> high-level abstraction of a request/response transformation.
>
> The current PSR-15 proposal has an implied architecture: a flat middleware 
> stack, the use of delegates, and the need for a dispatcher.
>
> These interfaces don't have those kinds of implications.
>
> Incidentally, if PSR-15 becomes the middleware standard, the 
> implementations of middleware-dispatchers could confirm with the 
> handler-interface I'm proposing without conflict - which would make it 
> possible to replace your PSR-15 dispatcher with any other 
> handler-implementation - which I think demonstrates the architectural 
> freedom provided by these much simpler high-level interfaces.
>
>
> On Mon, Apr 24, 2017 at 4:16 PM, Rivera, John  > wrote:
>
>> I may be re-treading a previous discussion, but as I read the discussion, 
>> I begun to ask: why? 
>>
>> Why do we need a PSR for this at all?
>>
>> HTTP request/response handling/filtering is very integral and ‘internal’ 
>> to a framework/library. There are many ways to approach this problem (as we 
>> have clearly seen), and they are largely self-contained within, and 
>> integral to, the framework.
>>
>> PSR-7 (as an example) makes complete sense because it enables inter-op 
>> between frameworks, libraries and projects.
>>
>> But this proposal — and PSR-15 along with it — is pushing the boundary of 
>> ‘inter-op’ and into ‘dictation’. I feel like we’re beginning to build an 
>> 'interface-framework’, which, in my humble opinion, is overstepping the 
>> role and purpose of the FIG.
>>
>> Let frameworks be themselves, and let them innovate. There’s no need for 
>> us to tell them how to do things like this.
>>

Re: Minimal HTTP middleware

[Michael Mayer]

Well, some work is already done:

   - Github Organisation: HTTP Message Strategies Interop 
   <https://github.com/http-message-strategies-interop>
   - pre-draft PSR HTTP Message Strategies 
   
<https://github.com/http-message-strategies-interop/fig-standards/tree/http-message-strategies/proposed/http-message-strategies>
   - Common interfaces for HTTP Message Strategies 
   <https://github.com/http-message-strategies-interop/http-message-strategies>
   - Some examples 
   
<https://github.com/http-message-strategies-interop?utf8=%E2%9C%93=example==>
 are 
   also available, notably:
   - A fork of David Négrier's symfony-httpinterop-bridge 
  
<https://github.com/http-message-strategies-interop/symfony-httpinterop-bridge>
   
Currently, the main difference, which is still up for discussion(!):

   - ServerAction:__invoke instead of Handler:handle
   
Some arguments for and against __invoke:

   - Pros, at the Meta Document 
   
<https://github.com/http-message-strategies-interop/fig-standards/blob/5d9084b1b65a75cefcccaca6ef6d1e55de4ac82c/proposed/http-message-strategies/http-message-strategies-meta.md#42-why-__invoke>
   - Pros+Cons, at Issues 
   <https://github.com/http-message-strategies-interop/fig-standards/issues>
   - Action vs. Handler at PR#5 
   <https://github.com/http-message-strategies-interop/fig-standards/pull/5>

I know, Rasmus and I disagree on __invoke, but I'm willing to go with the 
majority. For this reason, I invite Rasmus as an organisation member and 
everybody else who is interested to participate.

Bests,
Michael

On Wednesday, April 26, 2017 at 7:39:46 AM UTC+2, Rasmus Schultz wrote:
>
> I've set aside friday to write a draft of the handler PSR. We'll see how 
> FIG and the community responds and then work from there. 
>
>
> On Apr 25, 2017 22:44, "Michael Mayer" <mic...@schnittstabil.de 
> > wrote:
>
>> At the very least, we should standardize on a HandlerInterface, so that 
>>> PSR-15 doesn't ship with an identical, incompatible interface for delegates.
>>>
>>  
>> I couldn’t agree more.
>>
>> -- 
>> You received this message because you are subscribed to a topic in the 
>> Google Groups "PHP Framework Interoperability Group" group.
>> To unsubscribe from this topic, visit 
>> https://groups.google.com/d/topic/php-fig/B3jtdJA7-6w/unsubscribe.
>> To unsubscribe from this group and all its topics, 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/bdefb246-cc43-4ae2-a703-25b8beb288f8%40googlegroups.com
>>  
>> <https://groups.google.com/d/msgid/php-fig/bdefb246-cc43-4ae2-a703-25b8beb288f8%40googlegroups.com?utm_medium=email_source=footer>
>> .
>> For more options, visit https://groups.google.com/d/optout.
>>
>

-- 
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+unsubscr...@googlegroups.com.
To post to this group, send email to php-fig@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/php-fig/95c1312a-138b-400c-b521-bae86931dc70%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Minimal HTTP middleware

[Michael Mayer]

>
> At the very least, we should standardize on a HandlerInterface, so that 
> PSR-15 doesn't ship with an identical, incompatible interface for delegates.
>
 
I couldn’t agree more.

-- 
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+unsubscr...@googlegroups.com.
To post to this group, send email to php-fig@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/php-fig/bdefb246-cc43-4ae2-a703-25b8beb288f8%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Minimal HTTP middleware

[Michael Mayer]

On Friday, April 21, 2017 at 10:12:12 PM UTC+2, Rasmus Schultz wrote:
>
> Hi Michael :-)
>
> > As a handler objects holds a reference to the next handler object, it 
> is not reusable anymore.
>
> Well, the instance itself isn't "reusable" - but the code is, that's what 
> matters, isn't it?
>

Not always, I believe the current PSR-15 is superior in a React 
 environment. On first glance:

   1. less memory usage
   2. better GC 

 – but maybe I'm wrong on that.
 

> Callables in PHP are also objects, and a quick benchmark indicates 
> literally no difference between a closure and an idempotent functional 
> component - the creation overhead is more or less identical:
>
> https://gist.github.com/mindplay-dk/0d4e073179fedb9bb10663c3ffe22336
>

At first, you did it wrong :-) – see my gist comment. Secondly, you've 
mixed my two arguments, but my main concern was about naming things right, 
not about performance. To me Middleware is a pattern of Functional 
Programming:

   1. Middlewares are defined by lambdas/__invoke/…
   2. Middlewares use Continuation-Passing Style (CPS) 
   : 
   $next encapsulates the remaining computation

You know, I like the pattern you are proposing, but calling it Middleware 
does not fit to me: it is pure OOP. Calling it Middleware might sound sexy, 
but would need intense mental gymnastics to see a FP-Pattern.

I'm only aware of shelf  in the 
Dart world:

Middleware can be thought of as a function that takes a handler and wraps 
> it in another handler to provide additional functionality.


Hence, I'm not sure which Dart framework you are referring to (Btw, that is 
the same idea as Pythons Django 
 Middlewares, 
only the names differ).

Applying this idea to PHP, one probably comes up with these interfaces:

interface RequestHandler {
function __invoke(ServerRequestInterface $request);
}

interface Middleware {
function __invoke(RequestHandler $handler) : RequestHandler;
}

That Middleware interface also solve some __constructor issues, but 
obviously come with other disadvantages.

*tl;tr:* I love that pattern, but calling it Middleware sounds wrong.

About all your one-to-many successor concerns: I fully agree, and a Router 
is a good example which should not be implemented as a Middleware and 
moreover should not dispatch Middlewares. The current design I'm using, can 
be pictured as:




IMO, treating everything as Middleware is just as wrong as treating 
everything as RequestHandler. I want to use Middlewares to implement 
cross-cutting concerns, which justifies that they sit in the middle of the 
application stack, e.g. the LogMiddleware in the picture above. However, it 
would be strange to create multiple LogMiddleware instances: we have only 
one single log file. And it would also be strange, if LogMiddleware has a 
successor property, because that way it could only log things of a single 
successor.

Michael

-- 
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+unsubscr...@googlegroups.com.
To post to this group, send email to php-fig@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/php-fig/267f5a3d-2e5a-4db3-b41e-f90cdf149e37%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Survey: Naming things

[Michael Mayer]

Aw, sorry. BC := breaking change

On Thursday, April 13, 2017 at 5:33:39 PM UTC+2, Daniel Hunsaker wrote:
>
> On Thursday, April 13, 2017 at 8:55:25 AM UTC-6, Michael Mayer wrote:
>>
>> We should distinguish 3 cases:
>>
>>1. non-BCs, like adding methods etc.
>>2. BCs for some PHP versions, like adding parameter type declarations
>>3. BCs for all PHP versions, like adding return type declarations
>>
>> It would be advisable to focus on case 3. first – the other cases may 
>> depend on the outcome of it.
>>
>
> Trying to ensure I understand you - by BC here, do you mean 
> "backwards-compatible changes" (as the abbreviation normally indicates), or 
> "backwards compatibility breaks"?
>

-- 
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+unsubscr...@googlegroups.com.
To post to this group, send email to php-fig@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/php-fig/205f44cc-ca3c-4dfc-ab8b-dc59e838ab0b%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Survey: Naming things

[Michael Mayer]

Compatibility ftw!

Hence, a new namespace and a new composer package – I do not care about the 
concrete new names though:

namespace Psr\Log;

interface LoggerInterface
{
public function alert($message, array $context = array());
}


namespace Psr\Log\V2;

interface LoggerInterface
{
public function alert(string $message, array $context = array()):void;
}

class Logger implements \Psr\Log\LoggerInterface, \Psr\Log\V2\
LoggerInterface
{
public function alert($message, array $context = array()):void
{
// …
return;
}
}

Bests,
Michael Mayer

On Tuesday, April 11, 2017 at 10:19:08 PM UTC+2, Larry Garfield wrote:
>
> Hello, peoples.  In response to some recent off-list discussion (at 
> conferences and elsewhere), I offer this brief survey about how we 
> should namespace interface PSRs once we start producing "updated" 
> versions (eg, PHP 7-ified versions) of existing specs.  The survey 
> itself has more details, and should take under a minute to complete.   
> Please do so! 
>
>
> https://docs.google.com/forms/d/e/1FAIpQLSc8VJySoz_3koQThe057zYhzSkmOvOAgO0pEmenwr1Biu6JEA/viewform
>  
>
> This is a non-binding information gathering tool only to kick off a 
> discussion, not to end one.  Feel free to discuss more in this thread.   
> I'll leave the survey open for 2 weeks or until people stop responding 
> to it. :-) 
>
> All are welcome and encouraged to respond, even if you're not a Core 
> Committee member or Project Rep. 
>
> --Larry Garfield 
>
>

-- 
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+unsubscr...@googlegroups.com.
To post to this group, send email to php-fig@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/php-fig/b3e78d2b-72c3-44da-bfb1-be29db4302c6%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [PSR-15] Add a new interface for http errors

[Michael Mayer]

Great idea, though support for `HttpErrorException` make sense for every 
PSR-7 framework, not only PSR-15.

Thus, it has no dependence to middlewares and I see no reason to delay 
PSR-15 any further – it should be done in a new PSR.

Bests,
Michael Mayer

On Sunday, April 9, 2017 at 4:08:26 PM UTC+2, Woody Gilk wrote:
>
> Anyone else from PSR-15 (proposed) WG have comments?
>

Huh?

-- 
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+unsubscr...@googlegroups.com.
To post to this group, send email to php-fig@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/php-fig/235bad6d-dca0-46af-b66e-b9f0d5a2f5d2%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: PSR-5: declare @method and @property on directly to methods

[Michael Mayer]

On Tuesday, April 4, 2017 at 1:26:33 PM UTC+2, David Rodrigues wrote:

> If we can use {}, then we can keep it on class.
>

I assume so, see 5.4. Inline PHPDoc 
;
 but I 
would still prefer to write the docs as close at possible to the related 
code – see my example above or this example:

class Magic
{
// consider a class with many, many LOC

/**
 * @method $this method1(mixed $type) {
 * }
 *
 * @method $this method2() {
 * }
 *
 * @method $this method3() {
 * }
 */
public function __call($method, $parameters)
{
…
}
}

This would make navigation easier, wouldn't it?

-- 
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+unsubscr...@googlegroups.com.
To post to this group, send email to php-fig@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/php-fig/fdc0ff99-2dbe-49e8-95e1-f24ce47d73ec%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [PSR-15] Pipeline Pattern and Middelware Pattern

[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.

-- 
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+unsubscr...@googlegroups.com.
To post to this group, send email to php-fig@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/php-fig/8ee837f9-a613-4650-93fe-5ada71e004e2%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [PSR-15] Reloaded - Go!

[Michael Mayer]

I have neither claimed that you cannot nor that you will not be objective – 
do not try to read it into my comment.

Furthermore, do not try to downplay the Sponsor's role to a WG member with 
some administration tasks.
>From the fig-standards/bylaws/001-mission-and-structure.md 

:

*Sponsor*
> A PSR *must be sponsored by a member of the Core Committee*. […] *they 
> provide a level of oversight on the PSR's drafting on behalf of the Core 
> Committee*, […]
>
 

> *The Core Committee*
> […] The Core Committee is responsible for ensuring a high level of quality 
> and consistency amongst all published specifications, and that all relevant 
> perspectives and use cases are given due consideration.
> […] *Core Committee members are expected to consider the impact of their 
> actions on the PHP ecosystem as a whole when acting in their capacity as a 
> Core Committee member*


Sorry Matthew, honestly, I cannot remember one relevant comment off the 
cuff, where you have considered the impact of PSR-15 on a middleware 
framework other than your own. IMO that is permissible for an arbitrary WG 
member, but not for the Sponsor.

-- 
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+unsubscr...@googlegroups.com.
To post to this group, send email to php-fig@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/php-fig/01ff1d6f-7c67-446a-8328-152e9845e8c2%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [PSR-15] Reloaded - Go!

[Michael Mayer]

First, at this time, HTTP Factories (PSR-17) 
<https://github.com/php-fig/fig-standards/blob/master/proposed/http-factory/http-factory.md>
 must/should 
go first. PSR-15 1.2 Generating Responses 
<https://github.com/php-fig/fig-standards/blob/32ee7b1856a378c8e63ac8c295353ea5b498/proposed/http-middleware/middleware.md#12-generating-responses>
 
states:

It is RECOMMENDED that any middleware that needs to generate a response 
> will use HTTP Factories as defined in PSR-17, […]


Secondly, in my opinion, the Coordinator/Sponsor of a PSR should represent 
the interests of the FIG itself during the Draft and Review stages and also 
afterwards.
While I appreciate Matthew's contributions and especially his feedback 
based on implementing PSR-15 in Zend-Stratigility, he have had a great 
impact on very opinionated PSR-15 design decisions – which seems to be 
intended to advantage Zend-Stratigility (see http-middleware#24 (comment) 
<https://github.com/http-interop/http-middleware/pull/24#issuecomment-261794002>),
 
but may also create highly unexpected BCs for consumers (see Migration Issue 
<https://github.com/schnittstabil/stratigility-migration-issue> for 
example).
Sorry, but if Matthew also becomes the Sponsor of PSR-15, then I believe 
the independence and objectivity of PSR-Sponsors might reasonably be 
questioned.

Regards,
Michael Mayer

Am Sonntag, 19. März 2017 16:44:23 UTC+1 schrieb Adam Culp:
>
> I raise a motion that we get PSR-15 going again. The time for politics and 
> emotion have passed, and we need to get stuff done.
>
> We are past the date when pre-existing recommendations could slide in 
> under the old FIG bylaws, and so we must get PSR-15 into FIG 3.0 shape.
>
> Also, Paul M. Jones has elected not to continue with the FIG after 3.0 
> passed. Therefore we need a new Coordinator for PSR-15, which I believe 
> Matthew Weier O-Phinney had volunteered to take over.
>
> Once the previous 2 items are completed (convert to FIG 3.0 and get a 
> Coordinator) this recommendation is ready to go to vote. Let's get it going.
>
> Regards,
> Adam R Culp
> IBMiToolkit
>

-- 
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+unsubscr...@googlegroups.com.
To post to this group, send email to php-fig@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/php-fig/9bfa790b-cbb2-4628-aa21-b82a8b8aa549%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [REVIEW] PSR-16 Simple Cache

[Michael Mayer]

You can use `$default` in conjunction with the Null Object pattern 
. Whereby you usually 
don't want to cache *Null Objects*.

For example for message board users:

class UnknownUser implements User {…} // Null Object Class, providing 
proper avatar etc.

$unknownUser = new UnknownUser(); // N.B. $unknownUser is created only 
once, but can be reused multiple times 

// somewhere:
$user = $userCache->get('name of deleted user', $unknownUser);
$view->render('comment.html', ['user' => $user, …]);

This may make your code less complex 
, thus easier to read 
and understand – you do not need `if ($user === null) {…}` after each 
`->get()`.


Am Mittwoch, 15. März 2017 15:22:09 UTC+1 schrieb Brad Kent:
>
> I know I'm late to the party, but what's the use-case for passing a 
> default value to the get method?
>
> If we're using a cache isn't generating/getting the value expensive?
> It seems to encourage something boneheaded like: 
>
> $default = someExpensiveOperation();
> $myValue = $myCache->get('foo', $default);
>
> I could understand passing a callable that would set the value for a cache 
> miss...
>

-- 
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+unsubscr...@googlegroups.com.
To post to this group, send email to php-fig@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/php-fig/203c8680-35eb-487c-8af1-b1baf6115880%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: PSR-7 Alternate Proposal

[Michael Mayer]

John, would you mind pushing your interfaces and Stack to github? Thus, 
everybody interested can play with your code, which probably would reduce 
mails here.

-- 
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+unsubscr...@googlegroups.com.
To post to this group, send email to php-fig@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/php-fig/a2156982-48f3-424f-b14a-4cb81a6e5335%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: PSR-7 Alternate Proposal

[Michael Mayer]

Ok, despite some prototype related issues, I do not understand how you want 
to stack multiple RequestMiddlewareInterface instances?

For example one which adds the computation time, but only if the next 
middleware (e.g. the AuthHeaderMiddleware) returned with status === 200.



On Tuesday, February 21, 2017 at 8:09:36 PM UTC+1, John Porter wrote:
>
> Woody,
>
> Here's an example meeting your criteria (I think):
>
> 
> namespace Example;
>
> use Psr\Http\Message\MessageInterface;
> use Psr\Http\Message\RequestInterface;
> use Psr\Http\Middleware\RequestMiddlewareInterface;
> use Psr\Http\Middleware\ResponseFactoryInterface;
>
> class AuthHeaderMiddleware implements RequestMiddlewareInterface, 
> ResponseFactoryInterface
> {
> public function parseRequest(RequestInterface $request): 
> MessageInterface
> {
> if ($request->getMethod() === 'POST' && $request->hasHeader(
> 'authorization')) {
> return $request; // Passthrough here
> }
>
> $response = $this->createResponseInstance();
>
> return $response->withStatus(401); // short circuit handled by 
> middleware runner implementing ExchangeInterface
> }
> }
>  
>

-- 
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+unsubscr...@googlegroups.com.
To post to this group, send email to php-fig@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/php-fig/227f5190-8449-4546-a5c0-1d88f4340edc%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: PSR-7 Alternate Proposal

[Michael Mayer]

As far as I can see, the essential difference between PSR-15 and your 
proposal is about the responsibility for dispatching the next middleware:
1. with your version: it is determined at *compile time*, by implementing 
the appropriate interface; thus the stack should be responsible for it only.
2. with the PSR-15 version: it is determined at *run time*, thus the stack 
and the middleware are responsible for dispatching the next middleware.

Django, StackPHP and Guzzle for example, have chosen an approach which 
seems to align better to your version. In essence, their middlewares could 
be typed as:

(RequestInterface -> ResponseInterface) -> (RequestInterface -> 
ResponseInterface)

Or, if we want to use PHP interfaces only, then we could type them:

interface ExchangeInterface
{
public function __invoke(RequestInterface $request): ResponseInterface;
}

interface MiddlewareInterface
{
public function __invoke(ExchangeInterface $next): ExchangeInterface;
}

At first glance that could solve your issues with the current PSR-15, the 
*exchanger* does not seem to be responsible for dispatching the next 
exchanger and middlewares are simple exchange factories. And moreover we do 
not need middleware dispatchers anymore.

Unfortunately that isn't very attractive in PHP, a middleware would look 
like:

class UnicornMiddleware implements MiddlewareInterface
{
public function __invoke(ExchangeInterface $next): ExchangeInterface {
return new class($next) implements ExchangeInterface {
private $next;

public function __construct($next)
{
$this->next = $next;
}

public function __invoke(RequestInterface $request): 
ResponseInterface
{
return (($this->next)($request))->withHeader('X-PoweredBy', 
'Unicorns');
}
};
}
}

That's probably one of the reasons why StackPHP uses `__construct` and 
Guzzle uses closures. But even worse, the inner ExchangeInterface instance 
is still responsible for dispatching the next middleware :(

Are the PSR-15 interfaces so bad? From the perspective of a functional 
programmer, we can do some simple currying 
 to change the typing to get better 
interfaces:

(RequestInterface -> ResponseInterface) -> (RequestInterface -> 
ResponseInterface)
// using curry:
(RequestInterface -> ResponseInterface) -> RequestInterface -> 
ResponseInterface
// and again:
((RequestInterface -> ResponseInterface) -> RequestInterface) -> 
ResponseInterface

Again, if we use PHP `interfaces` only, the last version could look like 
this in PHP:

interface ExchangeInterface
{
public function __invoke(RequestInterface $request): ResponseInterface;
}

interface MiddlewareInterface
{
public function __invoke(ExchangeInterface $next, RequestInterface 
$request);
}

Aside from the parameter order, the similarities to the PSR-15 version are 
already obvious (Sadly, the names and implied contracts are very different 
and PSR-15 does not describe a functional middleware pattern anymore :cry: 
).

Anyway, the example above becomes much simpler with the current PSR-15 
interfaces:

class UnicornMiddleware implements ServerMiddlewareInterface
{
public function process(ServerRequestInterface $request, 
DelegateInterface $delegate) {
return $delegate->process($request)->withHeader('X-PoweredBy', 
'Unicorns');
}
}

Thus I believe your proposal does not fit better to the middleware pattern.

-- 
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+unsubscr...@googlegroups.com.
To post to this group, send email to php-fig@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/php-fig/b0794cd8-089a-4753-bbf5-9a3d0e833b06%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: PSR-7 Alternate Proposal

[Michael Mayer]

Hi John,

many thanks for your contribution. But as far as I can see, there is a big 
misconceptions about single responsibility principle (SRP) 
 and interface 
segregation principle (ISP) 
.

At first SRP; Robert C. Martin expresses the principle as follows:

A class should have only one reason to change.


SRP is NOT about objects, it is about classes. Objects are usually 
always(!) responsible for many things, for example a `car` object is 
responsible for the acceleration and the honking. SRP says only that a 
`car` class should not implement both responsibilities *by itself*! There 
are many ways we can have SRP in the car example. Delegation, inheritance 
and partial classes (traits) are the most common ones (e.g. wikipedia 
presents an example of SoC and partial classes 
, 
which is also an example for SRP).


Second, about your ISP considerations. Sorry, I cannot fully follow you on 
this. ISP is about:

> The interface-segregation principle (ISP) states that no client should be 
> forced to depend on methods it does not use. [Wikipedia]


The current `MiddlewareInterface::process(ServerRequestInterface $request, 
DelegateInterface $delegate)` is fully dedicated to the situation, when you 
need both: the request and a way to delegate requests. If you do not need 
both, then `MiddlewareInterface` is the wrong interface for your use case. 
And please note: the current PSR does not force you to use it in that 
cases. It just do not provide some additionally useful interfaces. – Should 
some of your proposed interfaces be added to PSR-15? I believe not, for 
example your `ResponseFactoryInterface` has nothing to do with *Middle*wares, 
the interfaces instances does not sit in the *middle* of some input and 
output. Hence, I believe it is fine to have it in PSR-17.

Btw, ISP is NOT about the PHP `interface` feature! Robert C. Martin uses 
the word *interface *in the same sense as in *graphical user interface*, 
*command 
line interface* or *network interface –* in the same meaning as *protocol* 
or *contract*. You may want to read his blog entry 'Interface' Considered 
Harmful 

 about 
the language feature.

Having said all that, thank you again for your thoughts – I share many of 
your concerns, but IMO most problems are not related the PHP `interfaces`, 
but to the contracts. For example `MiddlewareInterface::process` 

:
> * delegating to the next middleware component

Damn it! Why must a Middleware know, that other middlewares may be present? 
Is a Middleware responsible for the next one too???

Bests, Michael

Am Sonntag, 19. Februar 2017 15:48:02 UTC+1 schrieb John Porter:

> I've re-read everything that was discussed in my last issue #46 
>  and I realise 
> that having an example of an alternative that fixes my myriad of concerns 
> over swapping one flawed implementation for another (no offence meant), is 
> preferable over me just offloading my confusing concerns.
>
>
> I can clearly see my previous issue asked one question, then rambled about 
> other aspects of my concerns, so in an attempt to separate concerns (see 
> what I did there?) I will focus on a single response to this proposal.
>
>
> An Alternative Approach to Middleware
>
> I can see why a single pass approach is preferable to the double pass, but 
> in my mind, they are still both flawed and violate the single 
> responsibility principle and also the interface segregation principle.
>
>
> In both cases, the middleware is allowed to know too much about the entire 
> process of accepting a request, and expecting a response; whether that be 
> the double pass having a pre baked response instance, or the single pass 
> being told about the 'next' item in the chain.
>
> A Middleware should only care about what it is supposed to do in the 
> simplest way possible, enforcing the SRP.
>
>
> I am proposing that we really look at what the requirement is here, and 
> come up with something that fits the bill properly, rather than rehash 
> previous principles that smell bad. Here is something I started to touch on 
> in my issue, and that @schnittstabil  has 
> also touched on.
>
>
>  Psr\Http\Message\ResponseInterface;interface MiddlewareInterface{}
>
>
> We need a base interface that can allow type hinting a single point of 
> adding middleware to a queue for example.
>
>
>  Psr\Http\Message\ResponseInterface;interface ResponseFactoryInterface{
> public function createResponseInstance(): ResponseInterface;}
>
>
> We need an 

Re: Controllers and Filters PSR(s) ?

[Michael Mayer]

I would love to see an interface like your ControllerInterface,

but I believe most developers associate the word Controller with MVC etc. 
hence I believe the concerns about framework-territory are partially 
justified, the name would raise unrelated expectations.

In my opinion, "takes a request and returns a response" is the broadest 
> definition you can give and still imply that it's even an HTTP application.


Well, in that case I would suggest (similar to 
Symfony\Component\HttpKernel\HttpKernelInterface 
<https://github.com/symfony/symfony/blob/master/src/Symfony/Component/HttpKernel/HttpKernelInterface.php>
):

   - [Server]RequestHandlerInterface
   - [Server]RequestDispatcherInterface
   - [Server]RequestProcessorInterface

All of these are not burdened terms like Controller and the names work 
nicely in conjunction with concrete classes, e.g.:
class FooController implements RequestHandlerInterface {…}
class DefaultHandler implements RequestHandlerInterface {…}

The real benefit I see with such an interface is the absence of a framework 
– we do not need a MVC framework or a middleware stack/pipe/dispatcher to 
process a request, only a ServerRequestInterface instance is needed. 
Furthermore many libraries already support the signature of the interface 
method, which shows me that such an interface would not be too 
framework-specific, e.g. Aura.Router:
$ctrl = new Controller();

// add a route
$map->get('blog.read', '/blog/{id}', [$ctrl, 'dispatch']);

// or with an __invoke interface:
$map->get('blog.read', '/blog/{id}', $ctrl);

About the FilterInterface idea: honestly I would not bundle it with 
ControllerInterface. I believe, history has taught us that this is a bad 
idea, it only causes delays.


Bests,
Michael Mayer

Am Dienstag, 24. Januar 2017 17:45:56 UTC+1 schrieb Rasmus Schultz:
>
> Any interest in a simple PSR for Controllers?
>
> What I'm suggesting here is something that is extremely abstract and 
> generic - something that builds upon PSR-7.
>
> The interface itself could be as simple as this:
>
> interface ControllerInterface
> {
> public function dispatch(ServerRequestInterface $request): 
> ResponseInterface;
> }
>
> To contrast this with the middleware-interface of PSR-15, "middleware" is 
> a component that shares control with other middleware-components, e.g. 
> *may* do something to a request, or might just pass - as opposed to a 
> "controller", which is a component that *must* process the request and 
> create a response, so this would be something to which routing (of any 
> kind) has determined that, for the given request, this *is* the component 
> responsible for processing.
>
> This would work for front-controllers (such as a middleware-stack based on 
> PSR-15) as well as for any other types front-controllers, e.g. anything you 
> might use in a catch-all "index.php" as the top layer of request routing.
>
> It would work for any kind of action-controller as well, e.g. using 
> abstract base-classes to implement specific dispatch-strategies, and 
> assuming any other dependencies would be provided via dependency-injection 
> - which would be outside the scope of this PSR, but you can imagine 
> abstract base-classes implementing different dispatch-strategies, such as 
> dynamically mapping GET or POST params against argument-names of a run() 
> method, providing integration with a DI container, etc.
>
> We currently use such a strategy and an identical ControllerInterface at 
> work, and it's been a real success. Our default base-class, for example, 
> detects a JSON object body being posted, decodes it and maps 
> object-properties against arguments - and for form-posts, it checks for 
> scalar type-hints of the run-method and performs int, float and bool 
> conversions, array and string type-checks, etc.
>
> We enjoy the security of being able to replace our controller-pattern 
> completely without breaking compatibility with existing controllers, and 
> the freedom of being able to implement highly specialized controllers (such 
> as a controller that resizes images) without using a base-class at all.
>
> This pattern and interface makes any controller-implementation compatible 
> with any router capable of resolving a request to a ControllerInterface 
> instance, or perhaps a class-name for integration with a DI container. (In 
> our stack, that means the router is responsible solely for determining a 
> class-name - we use a class-per-action pattern, but a router could of 
> course also resolve to an action-method name and provide that to a 
> controller-implementation via constructor-injection - as with most patterns 
> this simple, your imagination seems to be the limit.)
>
> Basically any router that can resolve a path to a string and

Re: [PSR-12]

[Michael Mayer]

But we already have today:

declare(encoding='ISO-8859-1');
declare(ticks=1);

And for both holds: *the file is running a special mode of PHP, not the 
usual one.*
– Should I write all of them in the first line, or is strict_types such 
special?
– And, if so, what makes it such special?

Furthermore, at least for ticks, I see valid multi-line use cases:

Block declare statements are allowed and MUST be formatted as below. Note 
> position of braces and spacing:
> declare(ticks=1) {
> //some code
> }
>

Moreover:

 Each block MUST be in the order listed below, although blocks that are not 
> relevant may be omitted.
>
>- File-level docblock.
>
>
>- One or more declare statements.
>
>
>- The namespace declaration of the file.
>
>
>- …
>
> Hence, I know where they are, and *I don't need to scan around doc blocks 
and namespace declarations.*

Sorry, but I cannot see at the moment, how a consistent style 
recommendation may look like with that change.
However, I understand that declare statements are more important than the 
*File-level 
docblock –* thus why
not move them to the top of the list instead?

Best regards,
Michael Mayer

Am Sonntag, 4. Dezember 2016 18:50:55 UTC+1 schrieb Jordi Boggiano:
>
> I'm with Rudolph on this one, as I replied in the survey that was sent a 
> while back. IMO it should be on the first line to make sure it's visible 
> and not missed because it is such a meaningful line. It completely 
> changes the way the engine works, it's not php anymore, but strict php, 
> and you better be aware of it. 
>
> As for the fear that more flags will be added, well of course it's 
> possible but IMO unlikely. In any case we can revisit that topic if 
> needed when we have more flags, I don't think we need to set the rule of 
> today based on future unknowns. 
>
> Cheers 
>
> On 04/12/2016 14:48, Michael Mayer wrote: 
> > I disagree too. 
> > 
> > What, if PHP8 will introduce a new execution directive and PHP9 as well 
> > etc. And all of these are considered as good practice. 
> > Where should I put them? All in the same line? 
> > 
> > | 
> >  > 
> declare(strict_types=1);declare(php8_directive=1);declare(php9_directive=1); 
>
> > 
> > useFoo\Bar\Baz; 
> > 
> > classThingextendsBaz 
> > { 
> > } 
> > | 
> > 
> > Ewww! 
> > 
> > Best regards, 
> > Michael Mayer 
> > 
> > -- 
> > 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  
> > <mailto:php-fig+u...@googlegroups.com >. 
> > To post to this group, send email to php...@googlegroups.com 
>  
> > <mailto:php...@googlegroups.com >. 
> > To view this discussion on the web visit 
> > 
> https://groups.google.com/d/msgid/php-fig/07f36815-e178-42ee-b76c-42fa446fbfd9%40googlegroups.com
>  
> > <
> https://groups.google.com/d/msgid/php-fig/07f36815-e178-42ee-b76c-42fa446fbfd9%40googlegroups.com?utm_medium=email_source=footer>.
>  
>
> > For more options, visit https://groups.google.com/d/optout. 
>
>
> -- 
> Jordi Boggiano 
> @seldaek - http://seld.be 
>

-- 
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+unsubscr...@googlegroups.com.
To post to this group, send email to php-fig@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/php-fig/1f66926a-551f-4092-abb9-6c9bee83ebb9%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [PSR-12]

[Michael Mayer]

I disagree too.

What, if PHP8 will introduce a new execution directive and PHP9 as well 
etc. And all of these are considered as good practice.
Where should I put them? All in the same line?

https://groups.google.com/d/msgid/php-fig/07f36815-e178-42ee-b76c-42fa446fbfd9%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[PSR-11] Review of the delegate lookup requirement level

[Michael Mayer]

The current version is very confusing:

> 1.4 Additional feature: Delegate lookup
> This section describes an additional feature that *MAY* be added to a 
> container.
> …
> Implementation of this feature is therefore *RECOMMENDED*.


>From RFC 2119 :

> 3. *SHOULD*   This word, or the adjective "*RECOMMENDED*", mean that there
>may exist valid reasons in particular circumstances to ignore a
>particular item, but the full implications must be understood and
>carefully weighed before choosing a different course.
> …
> 5. *MAY*   This word, or the adjective "*OPTIONAL*", mean that an item is
>truly optional.  One vendor may choose to include the item because a
>particular marketplace requires it or because the vendor feels that
>it enhances the product while another vendor may omit the same item.
>An implementation which does not include a particular option MUST be
>prepared to interoperate with another implementation which does
>include the option, though perhaps with reduced functionality. In the
>same vein an implementation which does include a particular option
>MUST be prepared to interoperate with another implementation which
>does not include the option (except, of course, for the feature the
>option provides.)



Thus, as an implementer, *MAY* or *SHOULD* I implement the delegate lookup 
feature?

Regards,
Michael

-- 
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+unsubscr...@googlegroups.com.
To post to this group, send email to php-fig@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/php-fig/a788e26a-f305-4e50-8469-65464dcb49d7%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [PSR-15] Falsehoods About The Client-side

[Michael Mayer]

Hi Matthieu,

calling the root middleware seem to be a valid use case for server 
middlewares too:
If a middleware have to create (virgin) Requests, then calling the root 
middleware makes a lot more sense than calling the next middleware.

May you give me a hint where Joel mentioned this? – I can't find it.

Michael

Am Donnerstag, 3. November 2016 08:47:15 UTC+1 schrieb Matthieu Napoli:
>
> Definitely agree with making PSR-15 about server side middlewares only. 
> Joel mentioned several reasons why client-side middlewares needed something 
> different (e.g. the ability to reference the root middleware, for example 
> to follow a redirect through the whole stack again).
>
> Also that would maybe mean we can get rid of the dual 
> "MiddlewareInterface" and "ServerMiddlewareInterface"?
>
> Matthieu
>
> Le mercredi 2 novembre 2016 23:28:59 UTC+1, Michael Mayer a écrit :
>>
>> Woody,
>>
>> I have no experience in standardization processes, hence everything is 
>> acceptable to me. However, I see an additional benefit of two PSRs: it 
>> would be much easier to superseded them independently – hopefully that does 
>> never happen ;)
>>
>> Best regards,
>> Michael
>>
>> Am Montag, 31. Oktober 2016 14:50:39 UTC+1 schrieb Woody Gilk:
>>>
>>> Michael,
>>>
>>> Thanks for bringing this up. For historical context, I have always 
>>> thought of "client middleware" as middleware that does not require the 
>>> additional methods defined in ServerRequestInterface. The consideration of 
>>> async vs sync requests was never something that entered my mind.
>>>
>>> Reviewing the Guzzle docs again (as the most mature PSR-7 client-focused 
>>> package I know of) it certainly appears that the current PSR-15 signatures 
>>> would not work there. That is obviously a serious flaw.
>>>
>>> However, since there is not currently a ratified PSR for async, perhaps 
>>> the best thing to do would be to repurpose PSR-15 to be entirely 
>>> server-focused middleware? I would rather defer the creation of a spec for 
>>> client middleware until the async PSR is complete.
>>>
>>> Would that be an acceptable situation for you? I don't want to create 
>>> something that async clients will never be able to use.
>>>
>>> Regards,
>>>
>>> --
>>> Woody Gilk
>>> http://about.me/shadowhand
>>>
>>> On Sat, Oct 29, 2016 at 4:47 PM, Michael Mayer <mic...@schnittstabil.de> 
>>> wrote:
>>>
>>>> Hi everyone,
>>>>
>>>> I'm a little bit surprised to see so many suggestions about how 
>>>> ServerMiddlewareInterface and ClientMiddlewareInterface should look like, 
>>>> obviously without much knowledge about the client-side.
>>>>
>>>> The current state 
>>>> <https://github.com/php-fig/fig-standards/blob/82e2d1c1fd9a3782e0707cf0d4449b28cca8ffa9/proposed/http-middleware/middleware.md>
>>>>  
>>>> is:
>>>>
>>>> interface MiddlewareInterface {}
>>>>
>>>> interface ClientMiddlewareInterface extends MiddlewareInterface
>>>> {
>>>> public function process(RequestInterface $request, DelegateInterface 
>>>> $next);
>>>> }
>>>>
>>>> interface ServerMiddlewareInterface extends MiddlewareInterface
>>>> {
>>>> public function process(ServerRequestInterface $request, 
>>>> DelegateInterface $frame);
>>>> }
>>>>
>>>> interface DelegateInterface
>>>> {
>>>> public function next(RequestInterface $request);
>>>> }
>>>>
>>>>
>>>> <https://github.com/php-fig/fig-standards/blob/master/proposed/http-middleware/middleware.md#23-psrhttpmiddlewareclientmiddlewareinterface>
>>>>
>>>>
>>>>
>>>> Here are some falsehoods about the client-side, the list seems, by far, 
>>>> not exhaustive.
>>>>
>>>> *1. HTTP Clients return their results synchronously*
>>>> It would be very clumsy to load a web page nowadays with all its assets 
>>>> sequentially. Thus HTTP clients like Guzzle 
>>>> <https://github.com/guzzle/guzzle> use asynchronous techniques like 
>>>> Promises (e.g. Guzzle Promises <https://github.com/guzzle/promises>), 
>>>> callbacks (e.g. node.js), generator based control flow, etc.
>>>>
>>>&g

Re: [PSR-15] Falsehoods About The Client-side

[Michael Mayer]

Woody,

I have no experience in standardization processes, hence everything is 
acceptable to me. However, I see an additional benefit of two PSRs: it 
would be much easier to superseded them independently – hopefully that does 
never happen ;)

Best regards,
Michael

Am Montag, 31. Oktober 2016 14:50:39 UTC+1 schrieb Woody Gilk:
>
> Michael,
>
> Thanks for bringing this up. For historical context, I have always thought 
> of "client middleware" as middleware that does not require the additional 
> methods defined in ServerRequestInterface. The consideration of async vs 
> sync requests was never something that entered my mind.
>
> Reviewing the Guzzle docs again (as the most mature PSR-7 client-focused 
> package I know of) it certainly appears that the current PSR-15 signatures 
> would not work there. That is obviously a serious flaw.
>
> However, since there is not currently a ratified PSR for async, perhaps 
> the best thing to do would be to repurpose PSR-15 to be entirely 
> server-focused middleware? I would rather defer the creation of a spec for 
> client middleware until the async PSR is complete.
>
> Would that be an acceptable situation for you? I don't want to create 
> something that async clients will never be able to use.
>
> Regards,
>
> --
> Woody Gilk
> http://about.me/shadowhand
>
> On Sat, Oct 29, 2016 at 4:47 PM, Michael Mayer <mic...@schnittstabil.de 
> > wrote:
>
>> Hi everyone,
>>
>> I'm a little bit surprised to see so many suggestions about how 
>> ServerMiddlewareInterface and ClientMiddlewareInterface should look like, 
>> obviously without much knowledge about the client-side.
>>
>> The current state 
>> <https://github.com/php-fig/fig-standards/blob/82e2d1c1fd9a3782e0707cf0d4449b28cca8ffa9/proposed/http-middleware/middleware.md>
>>  
>> is:
>>
>> interface MiddlewareInterface {}
>>
>> interface ClientMiddlewareInterface extends MiddlewareInterface
>> {
>> public function process(RequestInterface $request, DelegateInterface 
>> $next);
>> }
>>
>> interface ServerMiddlewareInterface extends MiddlewareInterface
>> {
>> public function process(ServerRequestInterface $request, 
>> DelegateInterface $frame);
>> }
>>
>> interface DelegateInterface
>> {
>> public function next(RequestInterface $request);
>> }
>>
>>
>> <https://github.com/php-fig/fig-standards/blob/master/proposed/http-middleware/middleware.md#23-psrhttpmiddlewareclientmiddlewareinterface>
>>
>>
>>
>> Here are some falsehoods about the client-side, the list seems, by far, 
>> not exhaustive.
>>
>> *1. HTTP Clients return their results synchronously*
>> It would be very clumsy to load a web page nowadays with all its assets 
>> sequentially. Thus HTTP clients like Guzzle 
>> <https://github.com/guzzle/guzzle> use asynchronous techniques like 
>> Promises (e.g. Guzzle Promises <https://github.com/guzzle/promises>), 
>> callbacks (e.g. node.js), generator based control flow, etc.
>>
>> An example:
>>
>> $request = new \GuzzleHttp\Psr7\Request('GET', 'http://httpbin.org');
>> $promise = $client->sendAsync($request)->then(function ($response) {
>> echo 'I completed! ' . $response->getBody();
>> });
>>
>>
>> *2. Client Middlewares just transform Requests to Responses, doing it 
>> **synchronously 
>> is not a problem*
>> Maybe, this is appropriate on the server side, but not on the client. 
>> Just think about a Middleware which adds cookies to requests.
>>
>> From GuzzleHttp/Middleware 
>> <https://github.com/guzzle/guzzle/blob/5a5893c19f798175869eb94a88bb0b73e7acfb05/src/Middleware.php#L17-L44>
>> :
>> return function ($request, array $options) use ($handler) {
>> // …
>> $request = $cookieJar->withCookieHeader($request);
>> return $handler($request, $options)
>> ->then(function ($response) use ($cookieJar, $request) {
>> $cookieJar->extractCookies($request, $response);
>> return $response;
>> }
>> );
>> };
>>
>> The Middleware have to:
>>
>>1. add the current cookie to the header: ->withCookieHeader($request)
>>2. call the delegate: $handler($request, $options)
>>3. extract the cookie
>>
>> As the delegate returns a promise, we need to: $handler(…)->then(…).
>> Can we do better, e.g. use a sync delegate/handler? Nope, this would lead 
>> to call $promise->wait() within the delegate, which isn'