weaverryan · August 29, 2015 14:26
diff --git a/log.txt b/log.txt
 [2015-07-30 11:03:11] <weaverryan> Ok, let's get started
 [2015-07-30 11:03:35] <weaverryan> and of course, hi everyone - hope your summer's are interesting, etc etc :)
 [2015-07-30 11:03:44] <fabpot> Hi everyone
 [2015-07-30 11:03:46] → kbond joined ([email protected])
 [2015-07-30 11:04:00] <weaverryan> Let's roll into the first topic:
 [2015-07-30 11:04:12] <weaverryan> A) Deprecation triggering (nicolas-grekas)
 [2015-07-30 11:04:19] <weaverryan> which relates to this comment: https://github.com/symfony/symfony-docs/pull/5413#discussion_r35309129
 [2015-07-30 11:04:35] <weaverryan> nicolas-grekas: can you lead this discussion?
 [2015-07-30 11:05:30] → javier_eguiluz joined (uid41340@gateway/web/irccloud.com/x-xlpvdnhlzgzldktw)
 [2015-07-30 11:05:38] <nicolas-grekas> hello
 [2015-07-30 11:05:44] <nicolas-grekas> yes I can
 [2015-07-30 11:06:03] <nicolas-grekas> the topic is to agree on the new deprecation policy
 [2015-07-30 11:06:30] <nicolas-grekas> before 2.7, we did not add any trigger_error(), only comments and annotations
 [2015-07-30 11:06:52] <nicolas-grekas> now, we have @trigger_error() + phpunit-bridge
 [2015-07-30 11:07:10] <nicolas-grekas> we also have the @legacy annotation for tests
 [2015-07-30 11:07:36] → Garfield-fr joined (~Garfield-@unaffiliated/garfield-fr)
 [2015-07-30 11:07:41] <nicolas-grekas> my proposal is to continue with all of those
 [2015-07-30 11:07:51] <nicolas-grekas> for 3.0, 3.1, 4.x, etc
 [2015-07-30 11:07:53] ⇐ jspeck quit (~jspeck@2601:14d:8101:6b31:3424:17a5:b3d4:6cb1): Ping timeout: 244 seconds
 [2015-07-30 11:08:21] <nicolas-grekas> the benefit is to make deprecating properly a continuous process
 [2015-07-30 11:08:43] <nicolas-grekas> nobody wants to do again what we did for 2.7
 [2015-07-30 11:08:58] <nicolas-grekas> upgrading symfony itself to not use its own deprecated methods
 [2015-07-30 11:09:13] <weaverryan> Seems like adding trigger_error immediately (instead of waiting for a later version) would simplify the day-to-day process, right?
 [2015-07-30 11:09:14] <nicolas-grekas> that's it :)
 [2015-07-30 11:09:37] <nicolas-grekas> yes!
 [2015-07-30 11:09:58] <nicolas-grekas> and it forces a deprecation author to upgrade symfony
 [2015-07-30 11:10:17] <nicolas-grekas> which is right
 [2015-07-30 11:10:20] <weaverryan> any downsides? Maybe only that the author has a little bit more work in the PR
 [2015-07-30 11:10:21] <xabbuh> I think that's a good idea, since we now silence the triggered deprecation messages by default, there should be no real downside on the user's side
 [2015-07-30 11:11:23] <weaverryan> Related to this, why does a PR like this (to 2.8) not include trigger_error() https://github.com/symfony/symfony/pull/15131/files ?
 [2015-07-30 11:11:37] <romainneutron> it would ease major version transition a lot
 [2015-07-30 11:12:01] ⇐ tmporary quit ([email protected]): Quit: My Mac has gone to sleep. ZZZzzz…
 [2015-07-30 11:12:12] <nicolas-grekas> @ryan because interfaces should not trigger deprecations, the DebugClassLoader does it for them
 [2015-07-30 11:12:20] <jpauli> Hello :)
 [2015-07-30 11:12:56] <nicolas-grekas> that's maybe something we should write in the doc
 [2015-07-30 11:13:35] <weaverryan> most important is that the core teams know what to require / not require - I'm not super close to the trigger_error() efforts
 [2015-07-30 11:13:39] <weaverryan> So everyone seems to agree
 [2015-07-30 11:13:50] ⇐ ewgra quit ([email protected]): Quit: Leaving.
 [2015-07-30 11:14:11] <fabpot> it would be nice to add a small section in the contribution docs about that
 [2015-07-30 11:14:26] <fabpot> I think few people know that there is no need to do anything for interfaces for instance
 [2015-07-30 11:14:43] <nicolas-grekas> I'll upgrade the doc
 [2015-07-30 11:15:12] <weaverryan> Cool, easy win
 [2015-07-30 11:15:16] <weaverryan> Let's move on then
 [2015-07-30 11:15:21] <nicolas-grekas> ok
 [2015-07-30 11:15:32] <weaverryan> B) The PSR-7 Plan
 [2015-07-30 11:15:56] <weaverryan> which is *not* the same, dead topic I keep bringing up every 2 weeks - since there's been discussion internally on this during the past week :)
 [2015-07-30 11:16:37] <weaverryan> dunglas isn't here, so the question is: What approach should we take towards PSR-7. And before that, what are the problems we have that moving towards PSR-7 will solve?
 [2015-07-30 11:16:59] <weaverryan> (and btw, I have some opinions, but I'm not the most qualified person to lead this)
 [2015-07-30 11:18:02] → andrerom joined ([email protected])
 [2015-07-30 11:18:10] ⇐ andrerom quit ([email protected]): Quit: andrerom
 [2015-07-30 11:18:27] <fabpot> I think that asking the "why we should do that" is the right one
 [2015-07-30 11:18:39] → WouterJ joined ([email protected])
 [2015-07-30 11:18:47] <fabpot> We know that moving to an immutable HTTP foundation is going to break everything in Symfony
 [2015-07-30 11:19:52] <fabpot> I think trying to make the current HttpFoundation code look more like PSR-7 is a first good step
 [2015-07-30 11:20:10] <fabpot> trying to move mutable features into other classes, ...
 [2015-07-30 11:20:31] → webmozart joined ([email protected])
 [2015-07-30 11:20:34] <fabpot> we need to think also about how to make the Symfony HTTP events work with an immutable story
 [2015-07-30 11:20:37] → andrerom joined ([email protected])
 [2015-07-30 11:20:38] <webmozart> hi all
 [2015-07-30 11:21:11] <weaverryan> If PSR-7 is for middleware interop, and if we can get the PSR-7 bridge working perfectly, why have HttpFoundation be PSR-7? There's a benefit to them being similar, so you don't need to learn both, but we could make them similar
 [2015-07-30 11:21:43] <weaverryan> I'm trying to poke at the "why we should do that" question
 [2015-07-30 11:22:17] <fabpot> If you ask me, I don't see any real incentive to move towards PSR-7; it does not solve any problems that we have
 [2015-07-30 11:22:24] <fabpot> at least, none that I'm aware of
 [2015-07-30 11:22:26] <weaverryan> (ping lsmith)
 [2015-07-30 11:22:29] <WouterJ> weaverryan, because the bridge only solves a small part of PSR-7 support
 [2015-07-30 11:22:34] <WouterJ> hi btw :)
 [2015-07-30 11:23:27] <xabbuh> WouterJ: can the rest be solved in the bridge? and what are the parts that would need to be solved?
 [2015-07-30 11:23:27] <weaverryan> Assuming the bridge worked perfectly, what problems will I still have? What are the use-cases you're thinking of WouterJ?
 [2015-07-30 11:23:38] <WouterJ> i.e. I can't make a request listener that's dependent on PSR-7 purely. It would always need to be aware of the factory and convert it to a Symfony Request
 [2015-07-30 11:24:17] ⇐ romainneutron quit ([email protected]): Quit: romainneutron
 [2015-07-30 11:24:20] <weaverryan> request listener should be dependent on HttpKernel, os it would be written only for HttpFoundation. If you want it to be interop, make it a middleware that uses PSR-7
 [2015-07-30 11:24:28] <weaverryan> so*
 [2015-07-30 11:25:52] <WouterJ> hmm, you're right about the dependency. But is there native middleware support in Symfony?
 [2015-07-30 11:26:21] → romainneutron joined ([email protected])
 [2015-07-30 11:26:46] <weaverryan> WouterJ: It works fine with Symfony - we just haven't really organized the SE or documentation to push people in that direction
 [2015-07-30 11:27:04] → tmporary joined ([email protected])
 [2015-07-30 11:27:38] <WouterJ> hmm, as Forms are also fixed (or on the list to be fixed), I can't come up with any other thing this quickly
 [2015-07-30 11:28:17] <nicolas-grekas> Maybe we could have a component by component apporoach to psr-7 ?
 [2015-07-30 11:28:36] <nicolas-grekas> I mean: having a SE with PSR-7 inside has no value right now
 [2015-07-30 11:28:53] <nicolas-grekas> but using some component for building a psr-7 app (not SE) could have
 [2015-07-30 11:29:05] ⇐ DanielBadura quit ([email protected]): Read error: Connection reset by peer
 [2015-07-30 11:29:06] <nicolas-grekas> and may be simplier, on a component by component basis

 [11:33am] weaverryan: got myself disconnected momentarily - where are we now?
 [11:33am] weaverryan: I had seen nicolas-grekas comment about going component-by-component, but I wasn’t sure I understood
 [11:33am] weaverryan: and also: lsmith and dungals - both not here right now - would be the people who would think of reasons *for* doing PSR-7
 [11:34am] fabpot: seems like nobody have reasons  or nobody is listening 
 [11:34am] nicolas-grekas:
 [11:35am] weaverryan: if nobody is listening, then we can make some decisions 
 [11:35am] fabpot: drop PSR-7 support
 [11:35am] fabpot: let's vote 
 [11:36am] fabpot: nicolas-grekas suggests that we first try to support PSR-7 on some components (simple ones first: for instance, the Debug one)
 [11:36am] fabpot: that way, people using the Debug component outside of Symfony would be able to use it with a PSR-7 compliant framework
 [11:36am] andrerom: +1
 [11:37am] weaverryan: that’s a really good point
 [11:37am] fabpot: andrerom: is it a +1 to drop PSR-7 
 [11:37am] weaverryan: Then how would we use Debug with HttpFoundation?
 [11:37am] greg_ joined the chat room.
 [11:37am] xabbuh: sounds like a good plan (looking at one component after another)
 [11:37am] fabpot: weaverryan: we would of course still support HttpFoundation
 [11:37am] WouterJ: fabpot, but that would mean one of the 2 implementations requires the bridge?
 [11:37am] nicolas-grekas: we could add psr7 only methods for the psr7 mode
 [11:38am] xabbuh: I can imagine that there components that don't need any change at all (Yaml, for example)
 [11:38am] andrerom: for take it bit by bit, on demand, could make sense.
 [11:38am] fabpot: of course, there is nothing to do for most of the components
 [11:38am] WouterJ: or of course, extract input from the implementation. As most components only need some things of the request of course
 [11:38am] nicolas-grekas: in the Debug component, it's quite easy, there is only ExceptionHAndler->createResponse, to duplicate for psr-7
 [11:39am] weaverryan: brilliant
 [11:39am] WouterJ: Form is also pretty easy, by adding a Psr7 request handler
 [11:39am] andrerom: xabbuh: Yes you can claim support there and in Filesystem straigh away I think 
 [11:39am] jakubzalas left the chat room. (Quit: Leaving.)
 [11:39am] WouterJ: Security will be very hard. We need to extract HttpFoundation from Security\Http and then also implement a Security\Psr7
 [11:39am] fabpot: but the big PITA is going to be HttpKernel, for which i'm very relunctant as it wil basically break everything out there
 [11:40am] fabpot: But moving Security without HttpKernel does not make sense if you ask me
 [11:40am] fabpot: I'm pretty sure nobody uses Security without the full stack framework (and Silex)
 [11:40am] nicolas-grekas: Laravel?
 [11:40am] WouterJ: is there a real need to make HttpKernel PSR-7 compliant?
 [11:40am] fabpot: No
 [11:40am] WouterJ: laravel doesn't have security and such a high level
 [11:41am] WouterJ: however, I think Security can be quite usefull without HttpKernel. Currently using it together with Console for a secured console application
 [11:41am] weaverryan: I think we all agree it’d be great to have security support both - if someone does the works, awesome
 [11:41am] jjanvier_ joined the chat room.
 [11:41am] weaverryan: +1 for not converting http kernel to PSR-7
 [11:42am] weaverryan: (but making HttpFoundation more PSR-7 like and making sure that the bridge works perfectly)
 [11:42am] fabpot: +1 as well
 [11:43am] nicolas-grekas: I can take care of the Debug component
 [11:43am] nicolas-grekas:
 [11:43am] jpauli: -1 
 [11:43am] weaverryan: nicolas-grekas: that’ll be a nice way to show progress and set a precedent
 [11:43am] jpauli: no I'm joking 
 [11:43am] andrerom: +1 but tought that was implied by the decision to not do any breaks in 3.0, hence meaning it is forced to be postponed to 4.0 anyway.
 [11:44am] weaverryan: jpauli: since I know you in person, I thought you might be joking!
 [11:44am] fabpot: 4.0 is the same story, I don't see why we would change our mind
 [11:44am] jpauli: weaverryan: fabpot is in front of me in the office, so I watched his face when I sent my line ....  ; was funny 
 [11:45am] weaverryan: you missed the photo opportunity
 [11:45am] jjanvier left the chat room. (Ping timeout: 240 seconds)
 [11:45am] jpauli: anyway, I let you work now 
 [11:45am] andrerom: A future PSR maiking it more usefull, HTTP clients could for instance be a future extension
 [11:45am] andrerom: anyway, might never happen 
 [11:46am] WouterJ: Is 4.0 also not going to include breaks? I don't think that's good for Symfony innovation....
 [11:46am] nicolas-grekas: there is not diff in the bc-process between 3.0 and 4.0
 [11:46am] fabpot: we do break BC for each major version, but we try to keep an upgrade path
 [11:47am] nicolas-grekas: we move on to the next topic ? @ryan?
 [11:47am] andrerom: meaning 3.x should evolve to a state where code running on 4.0 should also be able to run on the last 3.x essentially
 [11:47am] weaverryan: I’ll summarize this discussion for after the meeting - there are a number of little deliverables
 [11:47am] weaverryan: Happily, I’m out of topics 
 [11:48am] weaverryan: There are other core initiatives that I emailed about - most of them can be found here https://gist.github.com/weaverryan/87fe0e8371f62685e6ad - but there isn’t anything to discuss, just work to be done
 [11:48am] WouterJ: (could someone then please click the close button of https://github.com/symfony/symfony/issues/15401 ?)
 [11:48am] weaverryan: boom
 [11:48am] weaverryan: #progress
 [11:49am] nicolas-grekas: I'm going to open an issue for tracking psr-7 support on a component by component basis
 [11:49am] weaverryan: So, let’s close the meeting - unless anyone else says anything in the next 60 seconds…
 [11:49am] nicolas-grekas: I you think that's a good idea
 [11:49am] andrerom: fabpot: Is there still a wish to add cache component at some point?
 [11:49am] WouterJ: has there ever been a wish?
 [11:49am] fabpot: we were waiting for PSR-X before doing anything
 [11:50am] fabpot: WouterJ: yes, we have some old/closed PRs on that
 [11:50am] andrerom: ok, clear. The one in D8 is good concept wise, but GPL
 [11:50am] weaverryan: andreom: and you guys need one? But can’t use the D8 cache due to the license?
 [11:50am] andrerom: It uses tags, good match for HTTP cache (see FOSHttpCache) and for data caching
 [11:51am] greg_: and what about https://twitter.com/julienPauli/status/479566649990066176 ? ping jpauli
 [11:51am] fabpot: We can revive some old PRs and see how to make them more or less compatible with the ucrrent PSR
 [11:51am] andrerom: weaverryan: We use Stash, but considering to switch as we need to tackle cache wipe outs on several operations, tags would helpe here
 [11:53am] andrerom: In in paralle we are also looking for ways to make FOSHttpCache support multi taging for PHP impl
 [11:53am] andrerom: For similar reasons
 [11:54am] weaverryan: andrerom: it seems like you guys have the most need. So if you have to put in the work already, then yea, perhaps we could include that work as a component
 [11:55am] weaverryan: ok, let’s close then
	[2015-07-30 11:03:11] <weaverryan> Ok, let's get started
	[2015-07-30 11:03:35] <weaverryan> and of course, hi everyone - hope your summer's are interesting, etc etc :)
	[2015-07-30 11:03:44] <fabpot> Hi everyone
	[2015-07-30 11:03:46] → kbond joined ([email protected])
	[2015-07-30 11:04:00] <weaverryan> Let's roll into the first topic:
	[2015-07-30 11:04:12] <weaverryan> A) Deprecation triggering (nicolas-grekas)
	[2015-07-30 11:04:19] <weaverryan> which relates to this comment: https://github.com/symfony/symfony-docs/pull/5413#discussion_r35309129
	[2015-07-30 11:04:35] <weaverryan> nicolas-grekas: can you lead this discussion?
	[2015-07-30 11:05:30] → javier_eguiluz joined (uid41340@gateway/web/irccloud.com/x-xlpvdnhlzgzldktw)
	[2015-07-30 11:05:38] <nicolas-grekas> hello
	[2015-07-30 11:05:44] <nicolas-grekas> yes I can
	[2015-07-30 11:06:03] <nicolas-grekas> the topic is to agree on the new deprecation policy
	[2015-07-30 11:06:30] <nicolas-grekas> before 2.7, we did not add any trigger_error(), only comments and annotations
	[2015-07-30 11:06:52] <nicolas-grekas> now, we have @trigger_error() + phpunit-bridge
	[2015-07-30 11:07:10] <nicolas-grekas> we also have the @legacy annotation for tests
	[2015-07-30 11:07:36] → Garfield-fr joined (~Garfield-@unaffiliated/garfield-fr)
	[2015-07-30 11:07:41] <nicolas-grekas> my proposal is to continue with all of those
	[2015-07-30 11:07:51] <nicolas-grekas> for 3.0, 3.1, 4.x, etc
	[2015-07-30 11:07:53] ⇐ jspeck quit (~jspeck@2601:14d:8101:6b31:3424:17a5:b3d4:6cb1): Ping timeout: 244 seconds
	[2015-07-30 11:08:21] <nicolas-grekas> the benefit is to make deprecating properly a continuous process
	[2015-07-30 11:08:43] <nicolas-grekas> nobody wants to do again what we did for 2.7
	[2015-07-30 11:08:58] <nicolas-grekas> upgrading symfony itself to not use its own deprecated methods
	[2015-07-30 11:09:13] <weaverryan> Seems like adding trigger_error immediately (instead of waiting for a later version) would simplify the day-to-day process, right?
	[2015-07-30 11:09:14] <nicolas-grekas> that's it :)
	[2015-07-30 11:09:37] <nicolas-grekas> yes!
	[2015-07-30 11:09:58] <nicolas-grekas> and it forces a deprecation author to upgrade symfony
	[2015-07-30 11:10:17] <nicolas-grekas> which is right
	[2015-07-30 11:10:20] <weaverryan> any downsides? Maybe only that the author has a little bit more work in the PR
	[2015-07-30 11:10:21] <xabbuh> I think that's a good idea, since we now silence the triggered deprecation messages by default, there should be no real downside on the user's side
	[2015-07-30 11:11:23] <weaverryan> Related to this, why does a PR like this (to 2.8) not include trigger_error() https://github.com/symfony/symfony/pull/15131/files ?
	[2015-07-30 11:11:37] <romainneutron> it would ease major version transition a lot
	[2015-07-30 11:12:01] ⇐ tmporary quit ([email protected]): Quit: My Mac has gone to sleep. ZZZzzz…
	[2015-07-30 11:12:12] <nicolas-grekas> @ryan because interfaces should not trigger deprecations, the DebugClassLoader does it for them
	[2015-07-30 11:12:20] <jpauli> Hello :)
	[2015-07-30 11:12:56] <nicolas-grekas> that's maybe something we should write in the doc
	[2015-07-30 11:13:35] <weaverryan> most important is that the core teams know what to require / not require - I'm not super close to the trigger_error() efforts
	[2015-07-30 11:13:39] <weaverryan> So everyone seems to agree
	[2015-07-30 11:13:50] ⇐ ewgra quit ([email protected]): Quit: Leaving.
	[2015-07-30 11:14:11] <fabpot> it would be nice to add a small section in the contribution docs about that
	[2015-07-30 11:14:26] <fabpot> I think few people know that there is no need to do anything for interfaces for instance
	[2015-07-30 11:14:43] <nicolas-grekas> I'll upgrade the doc
	[2015-07-30 11:15:12] <weaverryan> Cool, easy win
	[2015-07-30 11:15:16] <weaverryan> Let's move on then
	[2015-07-30 11:15:21] <nicolas-grekas> ok
	[2015-07-30 11:15:32] <weaverryan> B) The PSR-7 Plan
	[2015-07-30 11:15:56] <weaverryan> which is not the same, dead topic I keep bringing up every 2 weeks - since there's been discussion internally on this during the past week :)
	[2015-07-30 11:16:37] <weaverryan> dunglas isn't here, so the question is: What approach should we take towards PSR-7. And before that, what are the problems we have that moving towards PSR-7 will solve?
	[2015-07-30 11:16:59] <weaverryan> (and btw, I have some opinions, but I'm not the most qualified person to lead this)
	[2015-07-30 11:18:02] → andrerom joined ([email protected])
	[2015-07-30 11:18:10] ⇐ andrerom quit ([email protected]): Quit: andrerom
	[2015-07-30 11:18:27] <fabpot> I think that asking the "why we should do that" is the right one
	[2015-07-30 11:18:39] → WouterJ joined ([email protected])
	[2015-07-30 11:18:47] <fabpot> We know that moving to an immutable HTTP foundation is going to break everything in Symfony
	[2015-07-30 11:19:52] <fabpot> I think trying to make the current HttpFoundation code look more like PSR-7 is a first good step
	[2015-07-30 11:20:10] <fabpot> trying to move mutable features into other classes, ...
	[2015-07-30 11:20:31] → webmozart joined ([email protected])
	[2015-07-30 11:20:34] <fabpot> we need to think also about how to make the Symfony HTTP events work with an immutable story
	[2015-07-30 11:20:37] → andrerom joined ([email protected])
	[2015-07-30 11:20:38] <webmozart> hi all
	[2015-07-30 11:21:11] <weaverryan> If PSR-7 is for middleware interop, and if we can get the PSR-7 bridge working perfectly, why have HttpFoundation be PSR-7? There's a benefit to them being similar, so you don't need to learn both, but we could make them similar
	[2015-07-30 11:21:43] <weaverryan> I'm trying to poke at the "why we should do that" question
	[2015-07-30 11:22:17] <fabpot> If you ask me, I don't see any real incentive to move towards PSR-7; it does not solve any problems that we have
	[2015-07-30 11:22:24] <fabpot> at least, none that I'm aware of
	[2015-07-30 11:22:26] <weaverryan> (ping lsmith)
	[2015-07-30 11:22:29] <WouterJ> weaverryan, because the bridge only solves a small part of PSR-7 support
	[2015-07-30 11:22:34] <WouterJ> hi btw :)
	[2015-07-30 11:23:27] <xabbuh> WouterJ: can the rest be solved in the bridge? and what are the parts that would need to be solved?
	[2015-07-30 11:23:27] <weaverryan> Assuming the bridge worked perfectly, what problems will I still have? What are the use-cases you're thinking of WouterJ?
	[2015-07-30 11:23:38] <WouterJ> i.e. I can't make a request listener that's dependent on PSR-7 purely. It would always need to be aware of the factory and convert it to a Symfony Request
	[2015-07-30 11:24:17] ⇐ romainneutron quit ([email protected]): Quit: romainneutron
	[2015-07-30 11:24:20] <weaverryan> request listener should be dependent on HttpKernel, os it would be written only for HttpFoundation. If you want it to be interop, make it a middleware that uses PSR-7
	[2015-07-30 11:24:28] <weaverryan> so*
	[2015-07-30 11:25:52] <WouterJ> hmm, you're right about the dependency. But is there native middleware support in Symfony?
	[2015-07-30 11:26:21] → romainneutron joined ([email protected])
	[2015-07-30 11:26:46] <weaverryan> WouterJ: It works fine with Symfony - we just haven't really organized the SE or documentation to push people in that direction
	[2015-07-30 11:27:04] → tmporary joined ([email protected])
	[2015-07-30 11:27:38] <WouterJ> hmm, as Forms are also fixed (or on the list to be fixed), I can't come up with any other thing this quickly
	[2015-07-30 11:28:17] <nicolas-grekas> Maybe we could have a component by component apporoach to psr-7 ?
	[2015-07-30 11:28:36] <nicolas-grekas> I mean: having a SE with PSR-7 inside has no value right now
	[2015-07-30 11:28:53] <nicolas-grekas> but using some component for building a psr-7 app (not SE) could have
	[2015-07-30 11:29:05] ⇐ DanielBadura quit ([email protected]): Read error: Connection reset by peer
	[2015-07-30 11:29:06] <nicolas-grekas> and may be simplier, on a component by component basis

	[11:33am] weaverryan: got myself disconnected momentarily - where are we now?
	[11:33am] weaverryan: I had seen nicolas-grekas comment about going component-by-component, but I wasn’t sure I understood
	[11:33am] weaverryan: and also: lsmith and dungals - both not here right now - would be the people who would think of reasons for doing PSR-7
	[11:34am] fabpot: seems like nobody have reasons or nobody is listening
	[11:34am] nicolas-grekas:
	[11:35am] weaverryan: if nobody is listening, then we can make some decisions
	[11:35am] fabpot: drop PSR-7 support
	[11:35am] fabpot: let's vote
	[11:36am] fabpot: nicolas-grekas suggests that we first try to support PSR-7 on some components (simple ones first: for instance, the Debug one)
	[11:36am] fabpot: that way, people using the Debug component outside of Symfony would be able to use it with a PSR-7 compliant framework
	[11:36am] andrerom: +1
	[11:37am] weaverryan: that’s a really good point
	[11:37am] fabpot: andrerom: is it a +1 to drop PSR-7
	[11:37am] weaverryan: Then how would we use Debug with HttpFoundation?
	[11:37am] greg_ joined the chat room.
	[11:37am] xabbuh: sounds like a good plan (looking at one component after another)
	[11:37am] fabpot: weaverryan: we would of course still support HttpFoundation
	[11:37am] WouterJ: fabpot, but that would mean one of the 2 implementations requires the bridge?
	[11:37am] nicolas-grekas: we could add psr7 only methods for the psr7 mode
	[11:38am] xabbuh: I can imagine that there components that don't need any change at all (Yaml, for example)
	[11:38am] andrerom: for take it bit by bit, on demand, could make sense.
	[11:38am] fabpot: of course, there is nothing to do for most of the components
	[11:38am] WouterJ: or of course, extract input from the implementation. As most components only need some things of the request of course
	[11:38am] nicolas-grekas: in the Debug component, it's quite easy, there is only ExceptionHAndler->createResponse, to duplicate for psr-7
	[11:39am] weaverryan: brilliant
	[11:39am] WouterJ: Form is also pretty easy, by adding a Psr7 request handler
	[11:39am] andrerom: xabbuh: Yes you can claim support there and in Filesystem straigh away I think
	[11:39am] jakubzalas left the chat room. (Quit: Leaving.)
	[11:39am] WouterJ: Security will be very hard. We need to extract HttpFoundation from Security\Http and then also implement a Security\Psr7
	[11:39am] fabpot: but the big PITA is going to be HttpKernel, for which i'm very relunctant as it wil basically break everything out there
	[11:40am] fabpot: But moving Security without HttpKernel does not make sense if you ask me
	[11:40am] fabpot: I'm pretty sure nobody uses Security without the full stack framework (and Silex)
	[11:40am] nicolas-grekas: Laravel?
	[11:40am] WouterJ: is there a real need to make HttpKernel PSR-7 compliant?
	[11:40am] fabpot: No
	[11:40am] WouterJ: laravel doesn't have security and such a high level
	[11:41am] WouterJ: however, I think Security can be quite usefull without HttpKernel. Currently using it together with Console for a secured console application
	[11:41am] weaverryan: I think we all agree it’d be great to have security support both - if someone does the works, awesome
	[11:41am] jjanvier_ joined the chat room.
	[11:41am] weaverryan: +1 for not converting http kernel to PSR-7
	[11:42am] weaverryan: (but making HttpFoundation more PSR-7 like and making sure that the bridge works perfectly)
	[11:42am] fabpot: +1 as well
	[11:43am] nicolas-grekas: I can take care of the Debug component
	[11:43am] nicolas-grekas:
	[11:43am] jpauli: -1
	[11:43am] weaverryan: nicolas-grekas: that’ll be a nice way to show progress and set a precedent
	[11:43am] jpauli: no I'm joking
	[11:43am] andrerom: +1 but tought that was implied by the decision to not do any breaks in 3.0, hence meaning it is forced to be postponed to 4.0 anyway.
	[11:44am] weaverryan: jpauli: since I know you in person, I thought you might be joking!
	[11:44am] fabpot: 4.0 is the same story, I don't see why we would change our mind
	[11:44am] jpauli: weaverryan: fabpot is in front of me in the office, so I watched his face when I sent my line .... ; was funny
	[11:45am] weaverryan: you missed the photo opportunity
	[11:45am] jjanvier left the chat room. (Ping timeout: 240 seconds)
	[11:45am] jpauli: anyway, I let you work now
	[11:45am] andrerom: A future PSR maiking it more usefull, HTTP clients could for instance be a future extension
	[11:45am] andrerom: anyway, might never happen
	[11:46am] WouterJ: Is 4.0 also not going to include breaks? I don't think that's good for Symfony innovation....
	[11:46am] nicolas-grekas: there is not diff in the bc-process between 3.0 and 4.0
	[11:46am] fabpot: we do break BC for each major version, but we try to keep an upgrade path
	[11:47am] nicolas-grekas: we move on to the next topic ? @ryan?
	[11:47am] andrerom: meaning 3.x should evolve to a state where code running on 4.0 should also be able to run on the last 3.x essentially
	[11:47am] weaverryan: I’ll summarize this discussion for after the meeting - there are a number of little deliverables
	[11:47am] weaverryan: Happily, I’m out of topics
	[11:48am] weaverryan: There are other core initiatives that I emailed about - most of them can be found here https://gist.github.com/weaverryan/87fe0e8371f62685e6ad - but there isn’t anything to discuss, just work to be done
	[11:48am] WouterJ: (could someone then please click the close button of https://github.com/symfony/symfony/issues/15401 ?)
	[11:48am] weaverryan: boom
	[11:48am] weaverryan: #progress
	[11:49am] nicolas-grekas: I'm going to open an issue for tracking psr-7 support on a component by component basis
	[11:49am] weaverryan: So, let’s close the meeting - unless anyone else says anything in the next 60 seconds…
	[11:49am] nicolas-grekas: I you think that's a good idea
	[11:49am] andrerom: fabpot: Is there still a wish to add cache component at some point?
	[11:49am] WouterJ: has there ever been a wish?
	[11:49am] fabpot: we were waiting for PSR-X before doing anything
	[11:50am] fabpot: WouterJ: yes, we have some old/closed PRs on that
	[11:50am] andrerom: ok, clear. The one in D8 is good concept wise, but GPL
	[11:50am] weaverryan: andreom: and you guys need one? But can’t use the D8 cache due to the license?
	[11:50am] andrerom: It uses tags, good match for HTTP cache (see FOSHttpCache) and for data caching
	[11:51am] greg_: and what about https://twitter.com/julienPauli/status/479566649990066176 ? ping jpauli
	[11:51am] fabpot: We can revive some old PRs and see how to make them more or less compatible with the ucrrent PSR
	[11:51am] andrerom: weaverryan: We use Stash, but considering to switch as we need to tackle cache wipe outs on several operations, tags would helpe here
	[11:53am] andrerom: In in paralle we are also looking for ways to make FOSHttpCache support multi taging for PHP impl
	[11:53am] andrerom: For similar reasons
	[11:54am] weaverryan: andrerom: it seems like you guys have the most need. So if you have to put in the work already, then yea, perhaps we could include that work as a component
	[11:55am] weaverryan: ok, let’s close then