Because #1178246-80: Add Symfony2 HttpFoundation library to core raised this I have filed this issue, along with my rather strong opinion. Reopen if you have better ideas. I fail to see how the Drupal AOP system could be rebuilt on top of an OOP framework.
Comments
Comment #1
sdboyer commented@lsmith77 yeah...echoing Crell, there's a LONG road to getting the HttpKernel in. That starts to get into assumptions about how you model your overall application flow quite a bit more than the HttpFoundation. And yknow, while anything's possible, I would be be surprised if we got there. Some parts of it useful, I'm sure, but to get the "out of the box" ESI you describe would mean taking on a bit much.
Comment #2
gábor hojtsyWhat's the Drupal kernel?
Comment #3
sdboyer commented@Gábor Hojtsy ...which is part of the problem. Drupal hasn't formally delineated any kind of 'kernel' concept in the way that Symfony2 has. I think the most practical interpretation of this issue would be "for all Drupal subsystems with an analogue in the Symfony2 HttpKernel, replace them with with that analogue." However, the fact that there is no such clear kernel in Drupal is a good indicator of how difficult this would be.
It's probable that casting it in these terms might overrepresent the difficulty, but I agree with chx that it's largely infeasible, so it doesn't really matter.
Comment #4
jackbravo commentedsub
Comment #5
q0rban commentedsub
Comment #6
Crell commentedIMO, it's premature to even be asking this question, much less ruling it out entirely. I don't know that I'd even support such a move. I do know that simply declaring something as "no, never!" without even thinking it through, though, is generally a bad idea. So moving this to "postponed", meaning "we will get back to asking this question later when it's even worth thinking about", which is not right now.
Comment #7
cweagansIf I wanted to use Symfony, I'd use Symfony. Just my $0.02. Also, sub.
Comment #8
chx commentedSure, whatever. I already dislike HttpFoundation, my concerns are set aside as rant ( there's still no call chain posted, btw ) and not closing this is just disturbing. But, go ahead. Once upon a time, there was a Drupal... and now it's over. We made many mistakes in Drupal 7 and the way we are fixing them in D8 is just making Drupal even less Drupal-like.
Comment #9
lsmith77 commentedsubscribe
Comment #10
lsmith77 commented@cweagans: the main reason to use it would be that without such a "kernel" concept its hard to implement ESI properly in a predictable way, especially when thinking about various modules interacting. furthermore the component provides a PHP user land ESI reverse proxy that can provide huge speed boosts without requiring Varnish etc. But yeah I am not surprised that this is seen as very non trivial and probably something that should be looked at eventually but if we want to give it any chance of making it into Drupal8 it needs to be looked at soonish.
In summary: it would be a lot of work, but the pay off could be gigantic.
Comment #11
sdboyer commented@lsmith77 lemme rephrase my original comment a bit - we've been dealing with ESI questions inside of Drupal's current architecture for a long time (and yeah, PITA - but we know how to do it, and have a lot of experience making it happen in production). A lot of people - myself included - see the potential in WSCCI/D8 to apply those lessons, and are just itchingly-ready to introduce a structure that will be much more amenable to ESI (among other things). But, whereas sessions and an HTTP library are fairly well-encapsulated things that no Drupalfolk feel a ton of ownership over (afaik), this question of how we structure our responses is one that's been at the core of WSCCI since it was proposed back at DCSF, and a part of fundamental arguments about Drupal's approach to structuring its rendering for the last five years - at least.
I fully expect that when we get round to writing our system, we'll look a lot at HttpKernel/the choices sf2 has made. But it's not an unobtrusive switch - not at all. And there are too many people (myself included) invested in architecting the solution to this problem that's been plaguing us for years to punt on it.
So my 2c is...there are still prolly a lot of places we could benefit from pulling in sf2 code. And I'm all for that. But on this front, I think there'll be more pushback and bikeshedding than it's worth. So I'd like to see us focus on those lower hanging fruit :)
Comment #12
lsmith77 commentedSure .. btw this should be tagged with "symfony" as per http://drupal.org/node/1263478 .. right?
Comment #13
sdboyer commentedIndeed.
Comment #14
bojanz commentedLet's mark this as duplicate of #1463656: Add a Drupal kernel; leverage HttpFoundation and HttpKernel since that issue actually has a patch and is a result of newer conversations.