You must first sign up to be able to contribute.

Version 3 (modified by lsmith, 7 years ago)


We kind of went off script with the topics. Also note that in the end there wasnt a properly organized meeting afterwards, but the log is included at the end of this page .. but still lots of smaller groups discussing topics.

Replacing the current event manager with a Doctrine2 inspired version

No more new major core changes

What to include in the Standard Edition

IRC logs

[17:00] <lsmith> ok ..
[17:00] <lsmith> lets start
[17:01] <lsmith> bschussek would like to pull a wild card
[17:01] <lsmith> and discuss the event manager first
[17:01] <lsmith> he also has to leave early
[17:01] <lsmith> so
[17:01] <lsmith> bschussek: go!
[17:01] <bschussek> so, basically the idea is to change the current implementation of the EventDispatcher to something similar to Doctrine's EventManager
[17:02] → Dominique__ joined the channel.
[17:02] <bschussek> we can't reuse their implementation, because they optimized it for speed and we need more features
[17:02] <bschussek> but we can copy the API, which has several benefits
[17:02] • bshafs|away is now known as bshafs.
[17:02] <bschussek> the benefits are listed here:
[17:03] <lsmith> i guess the key question is how much performance loss is acceptable in what scenario
[17:03] <lsmith> fabpot: found a 5% performance loss in the hello world benchmark
[17:03] <bschussek> to sum up, event listener and dispatcher code becomes more readable, and users profit because of type safety and IDE hinting
[17:03] <lsmith> the loss might be larger bigger with security .. then again it might be lower as soon as you do more work
[17:03] <johanness> where is the loss coming from?
[17:03] <lsmith> johanness: i assume from the additional object creation?
[17:04] <johanness> there is none?
[17:04] <bschussek> lsmith: there is none
[17:04] <Stof> bschussek: reading the point about subscribers let me think that this was exactly was has been changed to lazy-load the listeners some weeks ago
[17:04] <bschussek> Symfony creates Event objects, DOctrine does
[17:04] <lsmith> thought EventArgs are now objects
[17:04] <bschussek> Symfony also creates an Event object when you dispatch it
[17:05] → beberlei joined the channel.
[17:05] <bschussek> here is the EM implementation:
[17:05] <lsmith> err right .. i meant "Event Listeners are objects, not callbacks."
[17:05] <bschussek> that doesn't count either, as in most cases the callbacks are methods of objects too
[17:05] <lsmith> but anyway .. again the key question is how much performance loss is acceptable in what test scenario
[17:06] <lsmith> discussing the exact implementation is beyond the scope of this meeting imho
[17:06] <bschussek> yes
[17:06] <Stof> lsmith: most listeners are still objects method now so the object is also instanciated
[17:06] <bschussek> I have to perform a benchmark, but judging from the above implementation, the performance loss should be minimal
[17:06] <fabpot> lsmith: I think the real question is not about performance
[17:06] <fabpot> but more: do we want to change this now?
[17:07] <fabpot> my point of view is to keep the current implementation
[17:07] <johanness> fabpot, are there reasons beyond the timing of this change?
[17:07] <beberlei> what are the disadvantages of the symfony event listener to remote it btw?
[17:08] <bschussek> beberlei:
[17:08] <fabpot> first reason is obviously the timing
[17:08] <fabpot> then, the current impl is well known (introduced in sf 1.1)
[17:08] <Stof> saying "we change to use the same interface than Doctrine but reimplementing it totally" seems weird when we still have a working implementation of an event dispatcher
[17:08] <fabpot> and last, I don't see any big benefit over the current code
[17:09] <lsmith> i think it will make developing events easier
[17:09] → dawinterfeldt joined the channel.
[17:09] <bschussek> fabpot: what about the benefits I listed in the commit?
[17:09] <fabpot> they are all minor. again, timing is really bad and as there is no big benefit, I'm -1
[17:10] <MagicalGradient> onSuccess(EventInterface $event) protected <-> onSuccess(RequestEventArgs $eventArgs) right one is less readable to me...
[17:10] <Stof> bschussek: the subcriber is not an advantage as it is exactly what was removed in the current implementation to lazy-load listeners
[17:10] <johanness> i think the big benefit is that it is much more explicit
[17:10] <bschussek> MagicalGradient: the name of the event object is a detail. The benefit is that you have an object with explicit methods
[17:10] <bschussek> so no $event->get('request'), but $event->getRequest()
[17:10] <lsmith> that being said .. i do not really know how much performance loss i would find acceptable
[17:10] <bschussek> and no $event->set('response', $response), but $event->setResponse($response) (type hinting!)
[17:11] <bschussek> so the new solution takes error management away from you
[17:11] <lsmith> yeah .. this is where i think it will ease development and debugging of events quite a bit
[17:11] <bschussek> you don't need to check $event->get('response') against an interface, because $event->getResponse() guarantees return values of a specific interface
[17:11] <MagicalGradient> The cool thing with the old implementation is that it uses the ParameterBag which is highly reusable...
[17:11] <fabpot> there is no Chekote/brokentest_democontroller_testindex
[17:11] <fabpot> oops
[17:12] <johnwards> the development and debugging events is key for me. Especially on 3rd party bundles
[17:12] <fabpot> let's try again, there is no $event->set('response', $response) in the current impl AFAIK
[17:12] <beberlei> MagicalGradient: an "array is also highly resuable", generic object collections are not an argument for something imho :)
[17:12] <johanness> fabpot, it's return $response
[17:12] <bschussek> fabpot: no, there is a "return $response" from the listener which is just as bad
[17:12] <johanness> and an additional call to setProcessed(true)
[17:13] <bschussek> when I refactored the code, this was hard to understand
[17:13] <bschussek> "processed" can have so many different meanings
[17:13] <lsmith> we have 3 more mins in this time box
[17:13] <bschussek> when you have custom events, you can tailor the "processed" to your needs
[17:13] <bschussek> for instance, hasResponse() etc.
[17:13] <MagicalGradient> +1 for stopPropagation() though..
[17:13] ← ivoaz left IRC. (Quit: Lost terminal)
[17:14] <Stof> bschussek: this method can also be renamed in the current implementation to make it clearer
[17:14] <MagicalGradient> much more clearer than notifyUntil...
[17:14] <bschussek> Stof: that's not the point
[17:14] • aways|bnc A+
[17:14] <bschussek> Event is used _everywhere_, you can't find a naming that fits every use case
[17:14] <bschussek> but if you have different Event classes, you can adjust the naming
[17:15] <johanness> yeah, personally, i like the change, and it's not as fundamental as ... eager response ;)
[17:15] <bschussek> also, because you implement own Event classes, they can contain their own logic
[17:15] <bschussek> e.g., the Event can decide that it is processed once you call setResponse($response) and that propagation should be stopped
[17:15] <lsmith> even though its a beefed up version of the Doctrine event handler .. its still quite similar
[17:15] <beberlei> bschussek: couldnt you just use specific even timplementations with the current approach also?
[17:15] <bschussek> listeners and dispatchers don't have to care about it
[17:16] <lsmith> so i think most users will need to understand its API anyway eventually
[17:16] <bschussek> beberlei: no, because currently there is no stopPropagation()
[17:16] <lsmith> but .. end of the time box reached
[17:16] <lsmith> we have lots of topics
[17:16] <lsmith> so moving on
[17:16] <lsmith> what to include in the Standard Edition?
[17:16] <bschussek> hum
[17:16] <fabpot> we cannot move on
[17:16] <fabpot> we need to make a decision
[17:16] <bschussek> yes
[17:16] <Stof> bschussek: this is what setProcessed is for
[17:16] <fabpot> and if it takes 1 hour, we won't be able to discuss anything else
[17:17] <lsmith> ok
[17:17] <Stof> stopping the propagation for a notifyUntil
[17:17] <bschussek> Stof: yes, but setProcessed() is semantically different
[17:17] <bschussek> it also says "yes this event was handled"
[17:17] <bschussek> and not just "please, no listener should do anything anymore"
[17:18] <naderman> how is that any different
[17:18] <beberlei> you could have an event handler that processes the result and does not stop the propagation
[17:18] <Stof> and notifyUntil is exactly that: call them until one says it has processed it
[17:18] <bschussek> exactly
[17:18] <bschussek> what beberlei said
[17:18] <beberlei> but you could do the same with notifyUntil
[17:18] <beberlei> just dont call setProcessed
[17:18] <beberlei> its sort of the same, just different api
[17:18] <Stof> just don't call setProcessed in this case
[17:18] <bschussek> beberlei: yes, but then the dispatcher is responsible for using the right method
[17:19] <bschussek> IMO encapsulating this logic in the Event class is much easier to understand
[17:19] <beberlei> call_user_func_array hmm
[17:19] <bschussek> ?
[17:19] <beberlei> well symfony dispatcher uses call_user_func_array, so every callback is allowed
[17:20] <beberlei> wheras doctrine "approach" has specific naming
[17:20] <tech13> Adding the routing logic to the event also makes it more restricted.  Request is processed, therefore since it is a notifyUntil, the additional filters would be skipped.
[17:20] <bschussek> no, I meant dispatcher method
[17:20] <bschussek> notify vs
[17:20] <bschussek> notifyUntil
[17:20] <bschussek> or filter
[17:20] <beberlei> ah
[17:20] <bschussek> tech13: what do you mean?
[17:20] <tech13> er /filters/logging or triggers/
[17:21] <bschussek> there is one more benefit with the new implementation, which is greater flexibility
[17:21] <bschussek> what if you want to filter a value but still stop propagation?
[17:21] → jonwage joined the channel.
[17:21] <tech13> bschussek, so if the event->setProcessed() triggers the event's behavior to stop going to the next listeners,
[17:21] <fabpot> bschussek: then, it's not a filter anymore
[17:21] <MagicalGradient> what if you want to filter a value but still stop propagation? -> true that
[17:22] <bschussek> fabpot: sure, but what do you use instead? notifyUntil with $event->set('foo', 'bar')?
[17:22] <bschussek> don't tell me that's easier
[17:23] <bschussek> any further questions?
[17:23] <fabpot> bschussek: I don't say one is easier/faster/more flexible than the other, I just say that it comes late in the game and that the benefits are not enough to change everything (think core code but also documentation, third-party bundles, ...)
[17:23] <cranberyxl> git status
[17:24] <bschussek> fabpot: we can copy the Doctrine documentation for a start. As for core code, everything has been migrated
[17:24] <fabpot> bschussek: last question: we won't depend on any Doctrine code, right?
[17:24] <beberlei> we are still in PR, so bc breaks even "late" in the game are still something people expect
[17:24] <bschussek> fabpot: no
[17:24] <bschussek> we'd replace the EventDispatcher implementation
[17:25] <lsmith> and i dont think it will affect that many people anyway
[17:25] <lsmith> and those affected will be the more advanced users
[17:25] <MagicalGradient> lsmith, this will break my apps...:D
[17:25] MagicalGradient has userhost and realname Christophe Eblé
[17:25] MagicalGradient is on #symfony-dev
[17:25] MagicalGradient is connected on (Vilnius, Lithuania, EU)
[17:25] MagicalGradient signed on at 07.03.2011 08:04:54 and has been idle for 16s
[17:26] <lsmith> wonder where the opensky guys are
[17:26] <bschussek> jonwage: are you there?
[17:26] <avalanche123> here
[17:26] <jonwage> yes
[17:26] <lsmith> kriswallsmith, avalanche123, jonwage
[17:26] <bschussek> afaik you were interested in that topic too
[17:26] <avalanche123> lsmith hi:)
[17:26] <jonwage> talking about events?
[17:26] <kriswallsmith> oh yeah, meeting
[17:26] → nostrzak joined the channel.
[17:26] <bschussek> yes
[17:27] <lsmith> essentially at this point fabpot isnt convinced that the benefits are worth it to bother at this point
[17:27] <lsmith> actually he doesnt really see the new approach to have much of any benefits to the new approach
[17:28] <lsmith> and we have deemed this topic to require a decision today
[17:28] <bschussek> jonwage, avalanche123, kriswallsmith: what's your opinion on this?
[17:28] <fabpot> lsmith: correct. But I won't use my veto on this one; so for the record, my vote is still -1. But if enough people are indeed in favor of this change, then let's do it (we will still have to work on names though).
[17:28] <jonwage> well, he has to see the benefits...what he's really saying is he doesn't think the benefit is greater then the cost of making the change and causing people to have to upgrade
[17:28] <kriswallsmith> i agree with everything fabpot has said, which is what i've also said on twitter and GH
[17:28] <kriswallsmith> -1
[17:28] <jonwage> technically it has benefits, no matter what ..its not about the technical decision right now..
[17:29] <jonwage> it just sucks for ppl to have to change their code
[17:29] <MagicalGradient> jonwage, +1
[17:29] <jonwage> and it won't technically change much for them..
[17:29] ← hidenorigoto left IRC. (Remote host closed the connection)
[17:29] <jonwage> but i think it is the right implementation for the long term
[17:29] <johanness> +1
[17:29] <bschussek> jonwage: what if we use a "mostly" BC solution?
[17:30] <vincentl> hey for the posts at symfonydevs, do they get validated by a moderator?
[17:30] <fabpot> bschussek: nope, we do the change or we don't change anything; but there is no point is being mostly compatible
[17:30] <jonwage> bschussek: that can help offset set it some but the cost of rewriting the application event code if you make use of lots of events could be a lot
[17:30] <bschussek> fabpot: what I mean is that I already taught the manager to accept callbacks
[17:31] <jonwage> bschussek: i think we should do it, so it adds 1-2 weeks of time on to the timeline for this change
[17:31] <jonwage> i think it is worth it for the next 10 years we will be building on symfony2 :)
[17:31] <bschussek> I agree
[17:31] <bschussek> votes?
[17:31] <jonwage> +1
[17:31] <pgodel_wor> if it really has technical benefits, then right now is not too late to make the change
[17:31] <lsmith> ok .. so i think at this point we can probably vote .. the vote result would just be "for consideration" for fabien
[17:32] <lsmith> he is the release manager
[17:32] <lsmith> and yes .. its late in the game
[17:32] <lsmith> ok?
[17:32] <kriswallsmith> i still don't see the technical benefits... but i want to see them :)
[17:32] <bschussek> kriswallsmith:
[17:32] <jonwage> they are all not totally tangible things kris
[17:32] <jonwage> its more about the quality of the end users implemented code
[17:32] <jonwage> if you have lots of events
[17:32] <jonwage> whats gonna be better, a class filled with different methods
[17:32] <bschussek> yes. You notice it when you use it
[17:32] <jonwage> handling events
[17:32] <jonwage> or multiple classes
[17:32] <jonwage> w
[17:33] <jonwage> ith clear interfaces
[17:33] <jonwage> with a name like PreUpdateEvent
[17:33] <jonwage> you know what that event gets
[17:33] <jonwage> the IDE can read it
[17:33] <jonwage> make sense?
[17:33] <jonwage> in symfony1 events are a mess because of this
[17:33] <pgodel_wor> that's how most other languages do events, I think
[17:33] <lsmith> right now there is a lot of stuff that relies on strings .. rather than class/interfaces
[17:33] <kriswallsmith> it's the binding of event name to method name?
[17:33] <tech13> I saw mention of something about lazy-load listeners.  How does that look in the DIC/XML?
[17:33] <bschussek> kriswallsmith: this, and that events use tailored Event objects
[17:34] <bschussek> so $event->getRequest() instead of $event->get('request')
[17:34] <jonwage> its just more close to the side of pure oo
[17:34] <kriswallsmith> bschussek: we can do that with the current code
[17:34] <avalanche123> bschussek, we could still tailor events as is, no? but subclassing Event
[17:34] <bschussek> or $event->setResponse($response) instead of return $response
[17:34] <avalanche123> *by
[17:34] <bschussek> I'm repeating myself, we currently don't have stopPropagation()
[17:34] <kriswallsmith> avalanche123: exactly
[17:34] <bschussek> without this, we can't do this
[17:34] <kriswallsmith> fabpot has explained that before -- this is based on apple's pattern
[17:35] <kriswallsmith> but we can change that within the current code
[17:35] <beberlei> i am +1 for this change also, it benefits in the long run
[17:35] <bschussek> kriswallsmith: to repeat my example, what if you want to filter a value, but stop propagation?
[17:35] <bschussek> you can't
[17:35] <fabpot> bschussek: and I will repeat myself: it's not filter then
[17:35] <bschussek> you can hack around it by using notifyUntil() with $event->set('foo', 'bar'), but that's not really clear
[17:35] <bschussek> fabpot: I never said that, I'm talking about realizing features, not naming things
[17:36] <fabpot> but anyway, I think we have discussed everything here, just let's vote and please only vote if you have actually had a look at the code and only if you understand the pros and cons
[17:36] <johanness> :)
[17:36] <MagicalGradient> -1
[17:36] <bschussek> +1
[17:36] <johanness> +1
[17:36] <kriswallsmith> -1
[17:37] <lsmith> what a tight race :)
[17:37] <avalanche123> could we do it in steps maybe? as in make specific even subclasses first?
[17:37] <kriswallsmith> it's neck and neck!
[17:37] <avalanche123> *event
[17:37] <bschussek> avalanche123: no, it wouldn't make sense
[17:38] <beberlei> +1
[17:38] <avalanche123> I can't vote, as I don't see strong improvements honestly, its just different, not better
[17:38] <lsmith> avalanche123: well that sounds like a -1 to me ..
[17:38] <fabpot> avalanche123: the vote is not about the technical side of things. It is whether we do the change or not
[17:38] <avalanche123> yeah -1
[17:38] ← rande left IRC. (Ping timeout: 252 seconds)
[17:38] <lsmith> obviously a change needs to have improvements
[17:39] <bschussek> jonwage?
[17:39] <lsmith> ok .. so then with fabpot -1 .. its -4 to +3
[17:39] <jonwage> I am +1 for the change
[17:39] <lsmith> ok +4 -4
[17:39] <bschussek> lsmith?
[17:39] <lsmith> i am not going to vote
[17:39] <avalanche123> aww
[17:40] <fabpot> naderman?
[17:40] <naderman> fabpot?
[17:40] <naderman> sorry wasn't following for a minute
[17:40] <naderman> vote on events?
[17:40] <bschussek> do you have a clear opinion and vote on events?
[17:40] <fabpot> naderman: ok, yes
[17:40] <lsmith> from what bschussek explained it sounds like a change for the better .. but i dont know the topic enough
[17:40] <naderman> +1 from me
[17:40] <jonwage> hmm
[17:40] • DeluxZ is now known as DeluxZ`food.
[17:40] <jonwage> wait have we shown examples?
[17:40] <jonwage> has everyone seen examples
[17:41] <kriswallsmith> yes
[17:41] <avalanche123> I read through commit message, but I would appreciate and example
[17:41] <naderman> mostly because of the notifyUntil stuff though
[17:41] <lsmith> the pull is one giantic example :)
[17:41] <beberlei> everybody that voted, must have read the commit otherwise his vote is void ;)
[17:41] <lsmith> hrhr
[17:41] <bschussek> just a moment...
[17:41] <lsmith> so now we are at -4 +5
[17:41] <jonwage> because all I see is how an old project of mine looks with symfony events and how it would look if i organized it better  with Doctrine events and the specific event type classes
[17:41] <bschussek>
[17:41] <jonwage> :)
[17:41] <johanness> we should create a test for everyone to pass before he can vote :)
[17:41] <jonwage> lol
[17:42] <avalanche123> :)
[17:42] <bschussek>
[17:42] ← johnwards left IRC. (Ping timeout: 250 seconds)
[17:43] <MagicalGradient> IMHO Only stopPropagation worth the change...
[17:43] <jonwage> so, we always talk about killing the magic in symfony2 :) that was a huge goal
[17:43] <bschussek>
[17:43] <jonwage> and the Event class here is still so magical
[17:43] <jonwage> we want explicitness right?
[17:43] <lsmith> i definately like the new versions better .. but like i said .. i dont know the current event system good enough to tell if similar improvements could be gotten by subclassing Event
[17:43] <jonwage> well explicit method names and explicit arguments for that event
[17:43] → rande joined the channel.
[17:43] <jonwage> is what this change is all about
[17:43] <jonwage> so i dont understand why we wouldnt do it
[17:43] <fabpot> jonwage: magic != explicit
[17:43] <jonwage> you have magic here with the event object
[17:43] <jonwage> how do I know what data is in it?
[17:43] <jonwage> i have to do what
[17:43] <jonwage> check the docs
[17:43] <jonwage> or print_r it
[17:44] <jonwage> if it was proper i could just use oo and check the api
[17:44] <jonwage> i know what object it is
[17:44] <jonwage> i can just click the method name in my ide
[17:44] <jonwage> but in the old symfony1 way of doing things this was never possible
[17:44] <avalanche123> well we could get rid of ParameterBag then in favor of request specific classes as in HomepageParameterBag, LoginParameterBag, etc
[17:44] <jonwage> but i think weve made a clear decision early on to FIX that problem
[17:44] <kriswallsmith> it's a convention, that's all
[17:44] → Groove- joined the channel.
[17:44] <bschussek> avalanche123: that doesn't help, you're still dealing with Event objects, not ParameterBags
[17:44] <jonwage> ya, symfony1
[17:45] ← ofus_ left IRC. (Read error: Connection reset by peer)
[17:45] <fabpot> do we still wait for someone to vote?
[17:45] <Stof> I'm +1
[17:45] → ofus_ joined the channel.
[17:45] <avalanche123> bschussek, I was just giving example
[17:45] <bschussek> avalanche123: sound's undecided, and as I know him he'll change his mind once he fully understands :)
[17:45] <avalanche123> bschussek :)
[17:46] <jonwage> getting a FilterResponseEventArgs $eventArgs instead of a EventInterface $event is way more clear to me
[17:46] <avalanche123> I am not 100% sure, that's true
[17:46] <kriswallsmith> i think we're throwing the baby out with the bathwater
[17:46] <jonwage> i cant just follow the class here to know what $event is
[17:46] <jonwage> its a dead end for the developer
[17:46] <lsmith> -4 +6
[17:46] <fabpot> ok, so, the community has decided
[17:46] <jonwage> of course, the people who dont vote the same as what i think just dont understand fully :) har har
[17:46] <cranberyxl> Event is just a message, it's up to the listener to interpret it
[17:47] <Stof> I think the name should be Event and not eventArgs as it is the event, not just the arguments but this can still be changed
[17:47] <avalanche123> actually, yes, I agree too, its like for parameters array instead of specific dependencies
[17:47] <bschussek> Stof: I agree, I will change this name
[17:47] <fabpot> Stof: we will need to work on the names for sure
[17:47] <jonwage> cranberyxl: right, what i am saying is with the new implementation the Message sis way more loud and clear
[17:47] <lsmith> ok next topic then
[17:47] <bschussek> it was taken from Doctrine
[17:47] <lsmith> what to include in the Standard Edition?
[17:47] <fabpot> lsmith: I have something else before continuing
[17:47] <avalanche123> I'm still unsure if its worth it
[17:47] <fabpot> sorry about that
[17:47] <lsmith> fabpot: ooookay :)
[17:47] <bschussek> avalanche123: let's talk about it later on IM?
[17:47] <fabpot> I want to be sure that everyone is on the same page about the current state of Symfony2
[17:48] <fabpot> is *now* on
[17:48] <fabpot> we are entering the final release cycle of Symfony2 and we badly need to finish everything, to stabilize features we have, to document them, and much more
[17:48] <avalanche123> bschussek yup
[17:48] <fabpot> and we all have other things to do of course
[17:48] <fabpot> just for the record, we still do not have a form component, locale is not finished yet, documentation is far from finished, ...
[17:48] <fabpot> so let's make it clear that this is the last discussion about changing a core feature like the one we have just discussed
[17:48] <lsmith> conversion to translation keys
[17:49] <fabpot> I will use my veto on any other big change before Symfony 2.0 final version, no matter what
[17:49] <kriswallsmith> ok
[17:49] <kriswallsmith> brb
[17:49] <lsmith> fabpot: does that include stuff like subrequest security? early response headers?
[17:49] <bschussek> fabpot: Locale is mostly finished, I'll send you the PR
[17:50] <fabpot> lsmith: I'm not talking about the current discussions we have. I'm talking about new changes
[17:50] <lsmith> ah ok
[17:50] <bschussek> I need to recheck everything again, but as far as I'm informed we can start testing
[17:50] <igorw> bschussek: did you see the PR message? I'd like to still fix the naming, but apart from that we're done
[17:50] <bschussek> igorw: yes
[17:50] <lsmith> yeah .. i agree .. the world must fall if we open another major topic at this point
[17:50] <naderman> fabpot: line needs to be drawn somewhere if it's ever going to get finished, so might as well be here and now :)
[17:51] <lsmith> ok .. so next topic? :)
[17:51] <beberlei> with the current architecture there is no problem changing stuff later also
[17:51] <fabpot> lsmith: yes, please
[17:51] <lsmith> beberlei: especially if we go private :)
[17:51] <lsmith> what to include in the Standard Edition?
[17:51] <lsmith> basically this was spawend over the inclusion of FrameworkExtraBundle
[17:51] <lsmith> though i generally got the vibe that the bulk of the people didnt mind to have it in
[17:51] <lsmith> but just that this is obviously not in core ..
[17:52] <lsmith> so the question was should it be moved to core?
[17:52] <johanness> what is the core?
[17:52] <lsmith> or should other non Symfony namespaced stuff potentially also be in SE
[17:52] <fabpot> lsmith: yes
[17:52] <lsmith> johanness: s/core/Symfony namespaced code
[17:52] <fabpot> the SE is about choosing a set of bundles, they do not need to be in "core"
[17:52] <lsmith> k
[17:52] <avalanche123> core is the minimum for framework to work imo
[17:52] <jonwage> fabpot how are we building the distributions?
[17:52] <jonwage> are you hand building them?
[17:52] → kris|m joined the channel.
[17:53] ← nostrzak left IRC.
[17:53] <fabpot> jonwage: bin/ to build the package
[17:53] <beberlei> avalanche123: well standard distribution is not called "core distribution"
[17:53] <lsmith> so we should start thinking if there is anything else to include ..
[17:53] <beberlei> its just what people should hcoose if they are indifferent
[17:53] <avalanche123> beberlei, exactly my point, no need to move bundles in core if they are part of standard distro
[17:53] → johnwards joined the channel.
[17:53] <lsmith> and if so what .. not sure if we need a formal process here .. or if we just do adoc vote decisions
[17:53] <avalanche123> standard is just optimized for solving standard problems
[17:53] <lsmith> agreed
[17:53] <fabpot> beberlei: yes, it's the bundles that most people will need for most common projects
[17:54] <Stof> the issue with SE is that it provides MongoDB but provide the 2.0.2 release of Doctrine\Common which is incompatible with it
[17:54] <fabpot> so, ORM is in, ODM is not for instance
[17:54] <jonwage> fabpot: it would be nice if users could go to the symfony website and build their own distribution, and everything is built for you by combining the chosen features/bundles + symfony2 directory structure and configuration..and packages it for you for download
[17:54] <Stof> fabpot: currently it is
[17:54] <lsmith> right .. so not all "core" Bundles will be included
[17:54] <beberlei> Stof: we already discussed that, the Common interfaces will be removed from mongodb for the first release
[17:54] <jonwage> we could have the 3-4 distributions we offer but really it is a pre chosen list of features/bundles
[17:54] <beberlei> jonwage has it on the todo list
[17:54] <jonwage> ok
[17:54] <johanness> jonwage, we need naderman sat resolver for this
[17:54] <jonwage> because then it doesnt really matter what we put in each distribution
[17:54] <fabpot> jonwage: this is what the packaging system is all about
[17:55] <jonwage> and we wouldnt ve having this discussion
[17:55] <jonwage> be*
[17:55] <jonwage> people need to not worry so much about what is in a distribution
[17:55] <naderman> err yes, it'd just be a set of default installed packages
[17:55] <jonwage> who cares, you can get exactly what you want just as fast
[17:55] <lsmith> jonwage: yes .. distributions are just a set of "defaults"
[17:55] <kris|m> +1 ala mootools
[17:55] <jonwage> cool
[17:55] <naderman> like if you get a linux distro it comes with a predefined set of packages that are installed
[17:55] <jonwage> can't wait :)
[17:55] <fabpot> jonwage: the idea of the distrib is to get started without messing with the CLI
[17:55] <Stof> btwn why is there no PR7 tag in the core repo ?
[17:55] <naderman> I need to hurry up :(
[17:55] <beberlei> so we agree? next topic :D
[17:56] → seb_m joined the channel.
[17:56] <fabpot> let's move on then
[17:56] <jonwage> ya you need to finish it, i feel like its a Mirage right now :)
[17:56] <Stof> this means the SD will always use the master branch when downloading it without the vendors
[17:56] <rande> a linux distribution also have a command to install new package ;)
[17:56] <lsmith> the topic isnt answered for me at all
[17:56] <lsmith> the question was what is in SE and what isnt
[17:57] <fabpot> lsmith: the real question is: what would you want to include that is not included yet?
[17:57] <MagicalGradient> ViewBundle xD
[17:57] <lsmith> ViewBundle for example :)
[17:57] <Stof> maybe FOS UserBundle for example
[17:57] <jonwage> Its still early, wouldn't we want to make everything easily available to them right now?
[17:57] <kris|m> -1
[17:57] <lsmith> FOSUserBundle
[17:57] <johanness> suprisingly, i think the SecurityBundle, and SecurityExtraBundle should be in there as well
[17:58] <lsmith> yeah .. i guess we can easily add new Bundles
[17:58] <fabpot> johanness: there already are in
[17:58] ← dbu left IRC. (Remote host closed the connection)
[17:58] <beberlei> Fos user bundle is way to unstable and still needs tests
[17:58] <fabpot> johanness: ah, not the SecurityExtraBundle
[17:58] <beberlei> it always breaks on me :D
[17:59] <lsmith> yes .. it needs tests!
[17:59] <lsmith> but being part of SE can be a motivation there :)
[17:59] <lsmith> ViewBundle also doesnt have tests
[17:59] <beberlei> no
[17:59] <fabpot> I think that this discussion about what to include should be postponed until we have stabilized things a bit more
[17:59] <beberlei> its tests first
[17:59] <beberlei> not tests when its in standard edition
[17:59] <beberlei> :p
[17:59] <lsmith> beberlei: agreed
[17:59] <lsmith> fabpot: aka .. so after RC1
[17:59] <lsmith> i can live with that
[18:00] <fabpot> lsmith: that makes sense I think
[18:00] <lsmith> ok time is up ..
[18:00] <lsmith> so we want to continue?
[18:00] <lsmith> hold an extra meeting?
[18:00] <lsmith> or just postpone until next week .. and talk on the ml in the mean time
[18:00] <beberlei> btw can someone recommend a symfony2 basics talk for me?
[18:00] <beberlei> i havent done anything for mine in the phpugcgn tomorrow :)
[18:00] <johanness> security subrequests should be solved asap
[18:01] <johanness> same as early response headers
[18:01] <fabpot> lsmith: that's what we get when deciding to change big things in the current core... delay
[18:01] <kris|m> I can continue
[18:01] <beberlei> well, i agree we dont have time for delays
[18:01] <beberlei> so continue or drop
[18:01] <Stof> I can too
[18:01] <lsmith> ok .. so lets focus on the topics that affect core
[18:01] <fabpot> I need to go for lunch now
[18:02] <beberlei> break?
[18:02] <lsmith> fabpot: i hope you mean dinner :)
[18:02] <lsmith> ok so break ..
[18:02] <pgodel_wor> lsmith: he's in canada
[18:02] <beberlei> i think he is one of the poor people freezing to death i ncanda :)
[18:02] <lsmith> i would say .. can we do a meeting tomorrow at 17:00?
[18:02] <fabpot> I will be back in about an hour
[18:02] <lsmith> pgodel_wor: oh right
[18:03] <lsmith> i will not be around then .. but i know that johanness will represent me well :)
[18:03] • lsmith kris|m
[18:03] ← bschussek left the channel.
[18:03] ← johnwards left IRC. (Ping timeout: 255 seconds)
[18:03] kris|m has userhost and realname Kris Wallsmith
[18:03] kris|m is on #symfony-dev
[18:03] kris|m is connected on (Evry, FR)
[18:03] kris|m signed on at 10.03.2011 17:51:55 and has been idle for 2min 37s
[18:03] <beberlei> running home then
[18:03] <kris|m> -1 for johanness getting 2 votes :)
[18:03] • bshafs is now known as bshafs|away.
[18:03] <lsmith> that was supposed to me /whois
[18:04] ← beberlei left IRC. (Quit: ChatZilla 0.9.86 [Firefox 3.6.15/20110303024726])
[18:04] ← pentarim left IRC. (Remote host closed the connection)
[18:04] <lsmith> kris|m: we have the same opinion on the matter :)

IRC logs of Part 2

[1:40 PM] <kriswallsmith> so, johanness needs answers for subrequest security and eager response headers
[1:40 PM] <kriswallsmith> shall we discuss?
[1:40 PM] <naderman> johanness: around?
[1:42 PM] <naderman> for eager response headers I think the only question left is whether there should be a generic core.response listener which takes a response header bag from the request and turns it into headers or whether there should be individual listeners turning request attributes into headers
[1:42 PM] <kriswallsmith> still doesn't seem right to me
[1:42 PM] <naderman> the latter solution avoids setting response headers before you have a response and at the same time it will probably be more code
[1:43 PM] <kriswallsmith> the purpose of having it eager is so a controller can make changes
[1:43 PM] <kriswallsmith> otherwise core.response would be sufficient
[1:43 PM] <naderman> there is another reason
[1:43 PM] <naderman> if you have code that needs to run in core.request to provide your controller with information, and based on that same information you also want to set headers in core.response
[1:44 PM] <naderman> then to avoid code duplication you need to either set the response header in core.request or add the header in core.response based on that piece of information you added to the request for the controller in core.request
[1:44 PM] <kriswallsmith> you could stash on the listener
[1:45 PM] <kriswallsmith> but then the controller couldn't make changes
[1:45 PM] <naderman> yes
[1:45 PM] <kriswallsmith> so the only reason is so the controller can make changes
[1:45 PM] <johanness> kriswallsmith, what if your listener is not responsible for setting the headers?
[1:45 PM] <naderman> stashing on the listener however makes it difficult with subrequests
[1:45 PM] <kriswallsmith> naderman: the listener should be request scope
[1:45 PM] <naderman> kriswallsmith: right that works too
[1:46 PM] <naderman> kriswallsmith: the problem johanness has with this is that he does not want to have a separate listener to set the headers
[1:46 PM] <Stof> not for security listeners unless the whole security is request scope
[1:46 PM] <kriswallsmith> johanness: in that case it has nothing to do with this discussion, right?
[1:46 PM] <naderman> which I don't really understand
[1:46 PM] <johanness> kriswallsmith, no the listener is delegating to another service
[1:46 PM] <naderman> johanness: I don't understand that?
[1:46 PM] <kriswallsmith> and the other service sets headers?
[1:47 PM] <naderman> you mean the service decides what headers need to be set and what needs to be provided to the controller?
[1:47 PM] <johanness> kriswallsmith, yes exactly
[1:47 PM] <naderman> but why wouldn't the service just stash the info internally until you ask it for the headers?
[1:48 PM] <kriswallsmith> the delegated service could listen to core.response
[1:48 PM] <johanness> i think having a lazy response header bag on the request is not gonna hurt, and seems like a good compromise to me
[1:48 PM] <naderman> so you ask the service something on core.request which makes it respond and generate info for the header
[1:48 PM] <naderman> and on core.response you ask the service to add its headers to the response
[1:48 PM] <kriswallsmith> my concern is that we put it there and the only time it's used in for security
[1:48 PM] <kriswallsmith> *is
[1:49 PM] <naderman> a generic response header bag also has little use for overwriting by a controller because it'd have to parse the headers to figure out what to modify
[1:50 PM] <johanness> kriswallsmith, but most people won't care anyway, it's not like it's affecting their code immensely
[1:50 PM] <naderman> I think I agree with kris on this, either store info in the listener / in the service the listener delegates to, or if the controller needs to overwrite it, put it into a request attribute
[1:50 PM] <kriswallsmith> we'll still have to maintain it
[1:50 PM] <naderman> that way we stay true to the idea of creating a response only once
[1:50 PM] <kriswallsmith> it adds complexity
[1:51 PM] <johanness> complexity?
[1:51 PM] <naderman> kriswallsmith: I think it's simpler actually, just not as "clean"
[1:51 PM] <kriswallsmith> yeah, merging in those headeres
[1:51 PM] <johanness> kriswallsmith, it will only be merged if there is a header bag
[1:51 PM] <naderman> hmm right it's intransparent in a sense so I guess you could say it's complex
[1:51 PM] <johanness> since most people won't use it, it will not be there
[1:51 PM] <naderman> johanness: yes but what do you do if there is a Content-Type header in the header bag
[1:52 PM] <naderman> do you overwrite the one in the response already?
[1:52 PM] <naderman> do you keep the one already in the response?
[1:52 PM] <johanness> but at least there is an easy way to set header from anywhere
[1:52 PM] <naderman> you can't afterall just send both
[1:52 PM] <kriswallsmith> on the otherhand, set-cookie should be allowed multiple times...
[1:52 PM] <kriswallsmith> complexity
[1:52 PM] <naderman> yes
[1:52 PM] <johanness> the response has precendence obviously
[1:53 PM] <naderman> ok so for Content-Type the response has precedence, for Set-Cookie they are both added (unless the cookie name is the same?)
[1:53 PM] <naderman> this really does sound rather complex
[1:53 PM] <johanness> naderman, we already have such kind of logic atm
[1:53 PM] <johanness> like setting a content type if none is present
[1:54 PM] <kriswallsmith> yes, but that's specific to content type
[1:54 PM] <naderman> johanness: but we don't have generic header merging code
[1:54 PM] <johanness> and to charset
[1:54 PM] <naderman> I mean this code would have to be able to consider _all_ possible headers
[1:54 PM] <naderman> and deal with them appropriately
[1:54 PM] <johanness> naderman, they are key value paris
[1:54 PM] <naderman> I mean what do you even do with X- headers?
[1:54 PM] <johanness> it's not a big deal
[1:54 PM] <kriswallsmith> johanness: it's not that simple
[1:55 PM] <kriswallsmith> the same key can be used multiple times
[1:55 PM] <naderman> johanness: they are key value pairs, where some keys may occur multiple times, but not all
[1:55 PM] <johanness> so which can occur multiple times?
[1:55 PM] <kriswallsmith> i don't think we can abstract a mechanism for this
[1:55 PM] <naderman> and you have no way of knowing which ones may or may not be added multiple times
[1:55 PM] <kriswallsmith> Set-Cookie
[1:55 PM] <naderman> johanness: any header I make up myself starting with X-
[1:55 PM] <johanness> ok cookies is special we already cover that
[1:55 PM] <naderman> but only if I want it to
[1:56 PM] <johanness> naderman, can you elaborate?
[1:56 PM] <kriswallsmith> i think each feature that needs this will have to implement its own explicit logic
[1:56 PM] <naderman> johanness: you can have custom headers, whether or not those are allowed to be duplicate is up to you
[1:56 PM] <kriswallsmith> which is fine, since most people won't use it
[1:57 PM] <naderman> Via is another header which can occur multiple times
[1:57 PM] <naderman> Warning too
[1:57 PM] <johanness> kriswallsmith, so you ask me to implement magic in security instead of having it in the kernel?
[1:57 PM] <kriswallsmith> yes
[1:57 PM] <naderman> Link too
[1:57 PM] <naderman> etc.
[1:57 PM] <kriswallsmith> behind the interface of the security component
[1:57 PM] <johanness> i don't see how headers are the domain of security
[1:57 PM] <naderman> johanness: the security thing is not magic, it is limited to Set-Cookies in one particular case
[1:57 PM] <naderman> you do not need generic header setting in security
[1:58 PM] <Seldaek> ah crap irc meeting..
[1:58 PM] <Seldaek> totally forgot
[1:58 PM] <kriswallsmith> Seldaek: this is part deux
[1:58 PM] <kriswallsmith> irc meeting reloaded
[1:58 PM] <naderman> <kriswallsmith> i think each feature that needs this will have to implement its own explicit logic <-- yes, best solution imho
[1:59 PM] <johanness> naderman, so we can have a early response cookies :)
[1:59 PM] <naderman> johanness: why do you keep insisting to make a generic solution for this, rather than solving the one problem at hand?
[1:59 PM] <johanness> because it's not easy to implement and the code gets quite ugly
[1:59 PM] <Stof> fabpot: here ?
[1:59 PM] <naderman> johanness: I disagree :D
[2:00 PM] <johanness> cookies should be fairly simple to implement and are the most common use case
[2:00 PM] <naderman> why don't you just set the cookies on core.response
[2:00 PM] <johanness> naderman, because of sub-requests etc.
[2:00 PM] <naderman> johanness: kriswallsmith already pointed out that the listner should have request scope
[2:00 PM] <naderman> so you don't need to worry about sub-requests
[2:01 PM] <kriswallsmith> johanness has pointed out that would add considerable overhead to security
[2:01 PM] <johanness> naderman, again that is not working for security
[2:01 PM] <naderman> well in that case use my solution?
[2:01 PM] <naderman> just stash listeners on sub-request core.request and unstash them on core.response?
[2:02 PM] <johanness> naderman, not trivial will make entire security even more complex
[2:02 PM] <naderman> you have that problem either way, even with "eager cookies"
[2:02 PM] <johanness> why?
[2:02 PM] <lsmith> johanness: tge question is in light of ESI .. how often will there really be subrequests for people that care about performance?
[2:02 PM] <kriswallsmith> you could either stash the response headers on the listener, organized by request using SplObjectStorage, or hijack a request attribute and stash the headers there
[2:02 PM] <naderman> johanness: where is the core.response listener that puts the cookies into the response?
[2:03 PM] <lsmith> so imho we should care about performance here so much
[2:03 PM] <naderman> lsmith: I do imagine they will be used a fair bit
[2:03 PM] <lsmith> the focus should be reliability and ease of maintenance
[2:03 PM] <naderman> lsmith: e.g. for the ajax-ability of requesting some sub-part?
[2:03 PM] <johanness> i mean i could implement a generic listener in the SecurityBundle which basically does that
[2:04 PM] <johanness> but i think it would better be placed in the ResponseListener
[2:04 PM] <lsmith> naderman: its easy to setup ESI and that is what people should go for .. at which point subrequests are turned into master requests
[2:04 PM] <naderman> right they will end up using AppCache anyway
[2:04 PM] <naderman> johanness: I think lukas is right, performance for sub-requests is not that important
[2:05 PM] <lsmith> meaning if we put a lot of effort into optimizing subrequests .. we are not benefiting ESI users
[2:05 PM] <johanness> another thing you should consider is how security integrates with other frameworks
[2:08 PM] <lsmith> johanness: which points to do see to consider there?
[2:09 PM] <naderman> I think other frameworks are all the more reason not to put something like a cookie stash into the framework
[2:09 PM] <naderman> because security would need to be able to deal with a framework that does not do that
[2:09 PM] <naderman> johanness: so I think that argument works against your solution ;-)
[2:09 PM] <johanness> naderman, not at all
[2:10 PM] <naderman> I mean having it inside security would work for other frameworks too
[2:10 PM] <johanness> naderman, but it is magically set on the response via stashing it in an splobjectstorage
[2:11 PM] <naderman> johanness: what?
[2:11 PM] <johanness> the contract of the interface is weakened
[2:11 PM] <naderman> I don't understand what you mean
[2:11 PM] <naderman> in which case is what stashed where?
[2:11 PM] <naderman> what solution are we talking about now?
[2:11 PM] <naderman> a cookie bag on the request in symfony2?
[2:11 PM] <naderman> or a cookie bag in the firewall?
[2:11 PM] <naderman> or no cookie bag at all?
[2:12 PM] <johanness> naderman, what solution are you talking about? :)
[2:12 PM] <naderman> johanness: the first one
[2:12 PM] <lsmith> i think at this point we have established that the remember me cookie needs to be checked at the start of the request
[2:12 PM] <lsmith> and that in the end something needs to be set on the reponse
[2:12 PM] <naderman> if you put the cookie bag into the symfony2 request class, then the security component will not work with a framework that cannot set cookies before it has a response
[2:13 PM] <lsmith> as such its clear we need to have some place to set something which will write into the reponse as soon as the reponse exists
[2:13 PM] <lsmith> agreed?
[2:13 PM] <naderman> yes
[2:13 PM] <naderman> the question is does it have to be a generic "write anything into request" or should there be a remember me cookie into response writer that is limited to this particular problem
[2:14 PM] <johanness> hm, ok we could have a general SecurityListener which only checks for one specific attribute
[2:15 PM] <johanness> that seems good, then i can still set it on the request but it would be no general set cookie feature
[2:15 PM] <naderman> yes
[2:15 PM] <naderman> that seems like a fair solution to me
[2:15 PM] <johanness> ofc if someone else uses that attribute it would be applied as well, but ok
[2:15 PM] <naderman> well make the name unique enough ;-)
[2:16 PM] <johanness> kriswallsmith, do you agree with this?
[2:16 PM] <naderman> although as per kriswallsmith, I'm not sure if a request attribute is necessarily the best place to store this
[2:16 PM] <kriswallsmith> using a request attribute?
[2:16 PM] <johanness> kriswallsmith, using a request attribute that only works for one specific cookie
[2:16 PM] <kriswallsmith> sounds good
[2:17 PM] <naderman> but it certainly solves the subrequest problem, so go for it
[2:24 PM] <beberlei> can someone point me to a good symfony introduction talk from one of the last conferences?
[2:24 PM] <beberlei> i need a starting point for my usergroup talk
[2:24 PM] <lsmith> beberlei: i used jordi last time
[2:24 PM] <lsmith> updated it last in early february IIRC
[2:24 PM] <lsmith> let me find it
[2:26 PM] <lsmith> beberlei:
[2:27 PM] <lsmith> specifically
[2:27 PM] <beberlei> do you have the raw also?
[2:27 PM] <lsmith> this is raw
[2:27 PM] <lsmith> you need slippy from github
[2:27 PM] <lsmith> its plain html
[2:27 PM] <lsmith> you can modify as you wish
[2:27 PM] <beberlei> its html
[2:27 PM] <beberlei> not plain html
[2:28 PM] <lsmith> its easy to edit .. this is the entire point of slippy
[2:28 PM] <lsmith> slippy also supports to in the end inline all css/js/images to make self contained versions
[2:28 PM] <beberlei> but i still have to write the code in <pre> and escape it myself?
[2:28 PM] <beberlei> doesnt look very easy to me
[2:29 PM] <beberlei> i use slidedown, which is a jquery plugin + markdown for previous talks
[2:29 PM] <lsmith> seems easy to me .. but thats all i can offer :)
[2:30 PM] <beberlei> thanks :D
[2:33 PM] <henrikbjorn> lsmith: you are the one taling to Mathew ? :)
[2:34 PM] <lsmith> henrikbjorn: uhm .. about what?
[2:34 PM] <henrikbjorn> zend stuff.. cant find the post where the zend component dependency tool is listed
[2:34 PM] <lsmith> i contacted him about maing zend\log less painful to include in Symfony2
[2:35 PM] <lsmith> henrikbjorn:
[2:35 PM] <henrikbjorn> YEEEESSS
[2:35 PM] <henrikbjorn> i owe you :)!!!!
[2:36 PM] <lsmith> do i get one "shut up now, no questions anymore" ? :)
[2:36 PM] <henrikbjorn> yes :)
[2:37 PM] <lsmith> juchu! :)
[2:38 PM] <johanness> ok, we still need to talk about subrequest security; atm, we do not secure sub-requests in the sense that everything in the configuration (access_control) is not applied to sub requests
[2:38 PM] <johanness> this can get especially confusing if you secure your controllers by relying on the _controller attribute
[2:39 PM] <naderman> I think security should work the same for subrequests as for regular requests
[2:39 PM] <lsmith> johanness: imho we should secure subrequests, but we should not try to get fancy with performance optimization
[2:39 PM] <naderman> so that ESI/no-ESI makes no difference from a security perspective
[2:39 PM] <johanness> lsmith, moving everything to scope request is not solving our problem
[2:39 PM] <lsmith> now one thing where i keep getting mentally confused is how to handle if inner requests then fail because the user does not have sufficient access rights
[2:40 PM] <johanness> i'm infact very unsure if that would work at all
[2:40 PM] <lsmith> its easy if the subrequest is done inside a controller
[2:40 PM] <lsmith> but less so when done inside a template
[2:40 PM] <henrikbjorn> the on-error thing for include tag ?
[2:40 PM] <johanness> the handle() method has a catch parameter
[2:41 PM] <lsmith> henrikbjorn: yeah .. i guess really thats all thats needed
[2:41 PM] <lsmith> aka .. either turn the entire request into failed .. or just ignore and return empty content
[2:41 PM] <henrikbjorn> you would still get the error in a log, and through you notification system get notified
[2:41 PM] <naderman> lsmith: so in a template having an "else" tag for sub requests would be cool
[2:42 PM] <naderman> but I guess that's what you meant by on-error :)
[2:42 PM] <henrikbjorn> naderman: cant be done
[2:42 PM] <johanness> what happens atm if there is a 404 exception in a sub-request?
[2:42 PM] <henrikbjorn> well not like the for twig tag
[2:42 PM] <naderman> henrikbjorn: sure, why not?
[2:43 PM] <naderman> it requires more complex ESI code hmm
[2:43 PM] <henrikbjorn> because with ESI the content would be injected into it, it will not evalutate after the tag
[2:43 PM] <naderman> it works as long as it's not standalone
[2:43 PM] <henrikbjorn> yes :)
[2:43 PM] <henrikbjorn> but essentially thats what on-error does, render a template if this request is not successful
[2:43 PM] <lsmith> johanness: afaik you have the options i mentioned .. fail the current request or ignore the subrequest
[2:44 PM] <lsmith> uhm .. "Varnish only supports the src attribute for ESI tags (onerror and alt attributes are ignored)."
[2:44 PM] <lsmith>
[2:45 PM] <henrikbjorn> thats a bommer
[2:45 PM] <naderman> henrikbjorn: there is <esi:try><esi:attempt></esi:attempt><esi:except></esi:except></esi:try> for this ;-)
[2:45 PM] <henrikbjorn> wow
[2:45 PM] <lsmith> "ignore_errors: if set to true, an onerror attribute will be added to the ESI with a value of continue indicating that, in the event of a failure, the gateway cache will simply remove the ESI tag silently."
[2:45 PM] <naderman> but I doubt varnish implements any of those
[2:45 PM] <henrikbjorn> lets not support that
[2:45 PM] <lsmith>
[2:46 PM] <Stof> lsmith: varnish does not support onerror
[2:46 PM] <lsmith> Stof: yeah .. thats a pretty big issue
[2:46 PM] <lsmith> so that means we need to make it possible for render tags to easily specify what they want to happen
[2:47 PM] <naderman> henrikbjorn: varnish argues that supporting stuff like ESI attempt/except makes no sense, because you can do the fallback inside VCL configuration
[2:47 PM] <naderman> same for onerror really
[2:48 PM] <lsmith> aka there needs to be a flag to catch the exception and instead return a Reponse with an empty content
[2:48 PM] <lsmith> standard > custom config
[2:49 PM] <lsmith> i knew it .. should have perstered that varnish guy some more
[2:49 PM] <lsmith> he brushed off my question with "such stuff isnt one size fits all"
[2:51 PM] <johanness> i think removing the ability to secure controller via configuration is probably the easiest solution
[2:52 PM] <lsmith> right .. it would at least prevent false expectations
[2:52 PM] <lsmith> but it would still lead to inconsistencies between ESI and non ESI
[2:52 PM] <johanness> hm, how do esi requests look like? what path do they have?
[2:53 PM] <johanness> maybe some special attribute?
[2:53 PM] <lsmith> johanness: they use an internal route .. so the path will look differently
[2:53 PM] <lsmith> hmm ..
[2:53 PM] <lsmith> so i guess there is no inconsistency in that case
[2:53 PM] <lsmith> since you would have to explicitly also secure the ESI paths
[2:54 PM] <lsmith> well it would still be inconsistent ... but less surprising
[3:00 PM] <johanness> fabpot, what is the status of ? this is kind of blocking any changes to security atm
[3:08 PM] <beberlei> lsmith, which slideset had this architecture image how the MVC request stack worked? symfony from the trenches?
[3:08 PM] <lsmith> beberlei: yes
[3:08 PM] <lsmith> i can send you the source for that .. its a google docs
[3:09 PM] <beberlei> thad would be nice, that is
[3:10 PM] <beberlei> hm no
[3:10 PM] <beberlei> thats not the one i meant
[3:10 PM] <beberlei> there was a nicer one somewhere else ;)
[3:10 PM] <fabpot> johanness: the problem with this PR is that there are many things in one PR
[3:11 PM] <fabpot> I can merge the protected/private changes
[3:11 PM] <lsmith> jonwage: i will upload a new copy of the trenches slides to slideshare ok?
[3:11 PM] <fabpot> but I want more time to think about the User/Account rename
[3:11 PM] <jonwage> ok cool
[3:20 PM] <fabpot> johanness: merged