You must first sign up to be able to contribute.


Response sub-classes vs. exceptions for HTTP status codes

Review: Services naming

Whats missing for RC1?

why parameters.ini?

"core" dev meeting in Paris

Naming collisions with Bundles

Cache warming

mongodb session storage

IRC logs

Mar 24 12:00:46 <lsmith>	so lets go
Mar 24 12:01:09 <lsmith>	Response sub-classes vs. exceptions for HTTP status codes:
Mar 24 12:01:12 <lsmith>	fabpot: ping
Mar 24 12:01:18 <lsmith>	kriswallsmith: ping
Mar 24 12:01:23 <fabpot>	pong
Mar 24 12:01:27 <kriswallsmith>	pong
Mar 24 12:01:30 <beberlei>	oink
Mar 24 12:01:48 <lsmith>	i guess both fabpot and kriswallsmith now think we shouldnt do this
Mar 24 12:01:58 <kriswallsmith>	yes, it takes control away from the user
Mar 24 12:02:04 <fabpot>	I created the 2 pull requests because I was not sure
Mar 24 12:02:05 <lsmith>	leaving me (and maybe Seldaek) who also think we should do this
Mar 24 12:02:25 *	johnkary ( has joined #symfony-dev
Mar 24 12:02:29 <fabpot>	I think this is more a documentation problem, than a technical one
Mar 24 12:02:33 <lsmith>	kriswallsmith: well we direct things to a central place by default
Mar 24 12:02:46 <jmikola|w>	is the argument against using sub-classes?
Mar 24 12:02:54 <jmikola|w>	i see nothing in the ML link other than Jordi's +1
Mar 24 12:03:03 <Seldaek>	jmikola|w: it's in the PR
Mar 24 12:03:08 <fabpot>	jmikola|w: everything is in the PRs
Mar 24 12:03:08 <kriswallsmith>	the centralized solution is there unless the user opts out of it by returning a response
Mar 24 12:03:25 <kriswallsmith>	so, +1 for addressing in documentation
Mar 24 12:03:45 <Seldaek>	and for my part, I'm not sure anymore if it's a good idea.. I think if we tell people to use exceptions, then it's ok if 4xx/5xx responses don't follow the same path, those are for more advanced use cases imo where you want to control everything
Mar 24 12:04:14 <Seldaek>	and in that case, I don't want my web service to return an exception page, I want to return a 405 and that's it
Mar 24 12:04:16 <lsmith>	johanness: ping
Mar 24 12:04:31 <jmikola|w>	is johanness' point about firewall needing to catch its access denied exception still valid?  or was he opting to use security-specific exceptions instead
Mar 24 12:04:32 <johanness>	i don't see the point in doing that via documentation. if we don't want users to return error responses then we should disallow it
Mar 24 12:05:11 <lsmith>	johanness: well its not that we dont want them to do that
Mar 24 12:05:14 <fabpot>	johanness: that's what my PR does
Mar 24 12:05:17 <lsmith>	its just that we want to prevent surprises
Mar 24 12:05:19 <Seldaek>	johanness: I don't see why it should be prevented, it just means you don't use the framework exception handler, but an error response isn't really an exception, it's just a response to the client to tell it that something went wrong
Mar 24 12:05:29 <lsmith>	but i can live with it being handled by documentation ..
Mar 24 12:05:39 <lsmith>	though i think we could just as well document how to undo the default
Mar 24 12:05:46 <kriswallsmith>	i don't think users will be surprised if the core.exception event isn't fired when an exception isn't thrown
Mar 24 12:05:55 <johanness>	fabpot, yeah i would change that to always throw a 500 exception saying that the user should throw an exception instead of return a response
Mar 24 12:06:06 <lsmith>	but i guess the PR handles hiding a user error while forcing advanced users to change defaults
Mar 24 12:06:17 <Seldaek>	kriswallsmith: yeah that's definitely true, the current way (pre-PR) is at least straightforward
Mar 24 12:06:27 <kriswallsmith>	i don't think that level of strictness is necessary johanness
Mar 24 12:06:54 <johanness>	kriswallsmith, but we want users to do that
Mar 24 12:07:07 <johanness>	why should we put that into the documentation otherwise?
Mar 24 12:07:07 <lsmith>	johanness: the question is do we?
Mar 24 12:07:11 <kriswallsmith>	it doesn't matter if they throw an exception or a response, it's up to them
Mar 24 12:07:14 <jmikola|w>	even internally, sf2 will not convert exceptions into error-specific response subclasses... it'll just be response objects with appropriate 4xx or 5xx error codes?
Mar 24 12:07:31 <lsmith>	for example returning a 405 response .. could be a way for json/xml requests to by pass the exception listener
Mar 24 12:07:38 <lsmith>	since most likely you dont want it triggered there
Mar 24 12:07:56 <kriswallsmith>	we shouldn't for a user into more abstraction
Mar 24 12:08:01 *	bschussek has quit (Quit: May the force be with you)
Mar 24 12:08:08 <fabpot>	jmikola|w: the question is not whether we need to create sub-classes or not; it's if we force developer to use exception for 4xx/5xx
Mar 24 12:08:24 <lsmith>	we should also not just focus on this aspect ..
Mar 24 12:08:25 <lsmith>
Mar 24 12:08:26 <jmikola|w>	reading through PR370, i'm in favor of core.exception functioning like core.view... it only steps in if an exception is received; i don't think strictness is necessary
Mar 24 12:08:50 <lsmith>	pull 370 is fairly clear cut .. you either favor one or the other
Mar 24 12:08:54 <johanness>	kriswallsmith, imo if we keep the flexibility, there is no point in advocating one solution over the other, e.g. we shouldn't put anything into the documentation
Mar 24 12:08:58 <lsmith>	PR 369 is a bit trickier from my POV
Mar 24 12:09:18 <jmikola|w>	fabpot: there seem to be many more 4xx and 5xx codes than we'd have exceptions for out of the box anyway... it might be limiting to mandate exceptions
Mar 24 12:09:53 <fabpot>	jmikola|w: read my post on the ML, everything is explained there
Mar 24 12:10:46 <lsmith>	johanness/fabpot: did you find a common ground on PR 369?
Mar 24 12:10:51 <lsmith>	and if so .. what is it?
Mar 24 12:11:02 *	kertz has quit (Ping timeout: 240 seconds)
Mar 24 12:11:09 <jmikola|w>	fabpot: yes, i see the list of what exceptions you're choosing to implement
Mar 24 12:11:10 <fabpot>	lsmith: not yet
Mar 24 12:11:19 <johanness>	we first need to settle on a general strategy imo
Mar 24 12:11:23 <lsmith>	ok
Mar 24 12:11:47 <kriswallsmith>	should be be concerned that http exceptions can be thrown from anywhere in the application?
Mar 24 12:11:54 <kriswallsmith>	i.e. from the model?
Mar 24 12:11:55 <lsmith>	so lets vote on PR 370 .. solve this by documentation or by forcing all 4x, 5x responses through the exception listener?
Mar 24 12:12:07 *	henrikbjorn ( has joined #symfony-dev
Mar 24 12:12:19 <johanness>	lsmith, what does "solve this by documentation" mean?
Mar 24 12:12:26 <kriswallsmith>	is this a community decision?
Mar 24 12:12:42 <lsmith>	johanness: document that if you want the exception listener triggerd .. throw an exception
Mar 24 12:12:51 <lsmith>	if you dont ... return a response
Mar 24 12:13:02 *	M00nShield has quit (Ping timeout: 240 seconds)
Mar 24 12:13:30 <iAsterisk>	why should response go through an exception listener?
Mar 24 12:13:43 <fabpot>	ok, let's stop this discussion, it's going nowhere
Mar 24 12:14:00 <iAsterisk>	from the outside it looks confusing.
Mar 24 12:14:04 <fabpot>	I'm going to close PR 370 and let things as they are now
Mar 24 12:14:05 <lsmith>	yes .. thats why i was asking for a vote
Mar 24 12:14:10 <lsmith>	ok
Mar 24 12:14:11 <kriswallsmith>	sounds good, let's move on
Mar 24 12:14:24 <lsmith>	what about PR 369?
Mar 24 12:14:31 <lsmith>	anything we can discuss here to move things along?
Mar 24 12:15:07 <lsmith>	ok .. since nobody is speaking up
Mar 24 12:15:09 <lsmith>	next topic
Mar 24 12:15:11 <lsmith>	Review: Services naming:
Mar 24 12:15:17 <kriswallsmith>	i'm still recusing myself from all security stuff
Mar 24 12:16:10 <lsmith>	i guess here the main question is if anyone is willing to spear head this?
Mar 24 12:16:20 <lsmith>	aka look through the list that jordi generated
Mar 24 12:16:22 <Seldaek>	yeha, I did my part with the grepping :p
Mar 24 12:16:31 <henrikbjorn>	define the naming, wasnt it about making some of them less verbose ?
Mar 24 12:16:32 <lsmith>	and try to find common naming patterns
Mar 24 12:16:35 <lsmith>	maybe document them
Mar 24 12:16:36 <fabpot>	lsmith: I will do that, it's on my todo list already
Mar 24 12:16:43 <lsmith>	ok
Mar 24 12:16:49 <lsmith>	then there is nothing to discuss there either?
Mar 24 12:16:49 <everzet>	cool
Mar 24 12:17:02 <Seldaek>	yeah I think it's good if fabpot can find time to do it, he has the best overview of everything
Mar 24 12:17:09 *	DrRotmos ( has joined #symfony-dev
Mar 24 12:17:18 <lsmith>	then moving on ..
Mar 24 12:17:24 <kriswallsmith>	re: doctrine.odm.mongodb.default_document_manager, should we create a persistence manager-manager?
Mar 24 12:17:27 <Seldaek>	fabpot: if you manage to pull out some naming-conventions out of it to add to the docs, even better
Mar 24 12:17:47 <everzet>	Seldaek: +1
Mar 24 12:17:49 <Seldaek>	'cause I've seen lots of horrible things done in bundles by random people
Mar 24 12:17:50 <fabpot>	Seldaek: I will try to find some naming conventions for sure
Mar 24 12:17:52 *	kertz (~kertz@ has joined #symfony-dev
Mar 24 12:18:02 <lsmith>	next topic then: Whats missing for RC1?
Mar 24 12:18:11 <lsmith>	not sure if anything has changed since last week really
Mar 24 12:18:16 <henrikbjorn>	kriswallsmith: would be nice, but confusing if you use odm and orm at the same time
Mar 24 12:18:17 <Seldaek>	forms, but nvm :)
Mar 24 12:18:22 <kriswallsmith>	i think all public services should use only _ no .
Mar 24 12:18:38 <Seldaek>	kriswallsmith: ah weird, I liked the dots
Mar 24 12:18:55 <Seldaek>	I think they denote nesting much better than underscores
Mar 24 12:18:56 <fabpot>	I have converted many components to private usage
Mar 24 12:18:56 <jmikola|w>	kriswallsmith: dots are helpful for namespacing
Mar 24 12:18:57 <everzet>	kriswallsmith: dots is better
Mar 24 12:19:06 <everzet>	kriswallsmith: *ARE better
Mar 24 12:19:11 <fabpot>	but some still need to be done: Serializer, Form, and Validation
Mar 24 12:19:20 <kriswallsmith>	we should have very few public services
Mar 24 12:19:22 <Seldaek>	aye, it's on my todo
Mar 24 12:20:05 <Seldaek>	kriswallsmith: still, it just feels more natural to use <some_ns>.<name>, looks like twig variables
Mar 24 12:20:08 <henrikbjorn>	private = cant be changed or ?
Mar 24 12:20:11 <lsmith>	anything else that has changed since last week in terms of getting to RC1?
Mar 24 12:20:21 <lsmith>	fabpot: one question .. so the next release will be called beta1?
Mar 24 12:20:23 <lsmith>	or RC1?
Mar 24 12:20:25 <Stof>	henrikbjorn: can't be retrieved at runtime
Mar 24 12:20:31 <henrikbjorn>	ok
Mar 24 12:20:34 <lsmith>	and if beta1 .. will we also have an RC phase?
Mar 24 12:20:38 *	mapi_ has quit (Ping timeout: 255 seconds)
Mar 24 12:20:40 <everzet>	lsmith: RC without beta's is quite extreme :-)
Mar 24 12:20:42 <fabpot>	lsmith: beta1 as we won't have the service renames for instance
Mar 24 12:20:43 <lsmith>	just because i have seen some people wondering
Mar 24 12:20:51 <lsmith>	ok
Mar 24 12:20:54 <everzet>	lsmith: but i think our current PR's is already beta's
Mar 24 12:20:55 <fabpot>	some betas and then some RCs
Mar 24 12:21:19 <lsmith>	ok .. then moving on to the next topic -> why parameters.ini?
Mar 24 12:21:21 <fabpot>	everzet: beta means that all features are there but with bugs ;)
Mar 24 12:21:31 <Seldaek>	fabpot: ah right, something I wanted to mention, I've seen so many people asking when/what about the final, I think they deserve an update on the official blog to say what's the current state
Mar 24 12:21:45 <Seldaek>	because we are all up to speed here, but the users at large aren't
Mar 24 12:21:45 <everzet>	fabpot: it's strange, but i was always thought it is RC :-D
Mar 24 12:22:04 <fabpot>	everzet: RC means that we won't break BC
Mar 24 12:22:14 *	nostrzak ( has joined #symfony-dev
Mar 24 12:22:21 <lsmith>	fabpot: basically many of us have been wondering why the SE uses ini format
Mar 24 12:22:24 <fabpot>	Seldaek: right, I will do that when announcing the beta1 next week
Mar 24 12:22:32 <lsmith>	what is the motivation for this?
Mar 24 12:22:34 <Seldaek>	ok cool
Mar 24 12:22:43 <lsmith>	given the flexibility of ini parsing in php 5.3 ..
Mar 24 12:22:48 <everzet>	fabpot: :-D Ok. It's just me. I've thought that beta is just betta than nothing...
Mar 24 12:22:49 <fabpot>	lsmith: because some people don't like YAML, some others don't like XML, and many don't like PHP for configuration
Mar 24 12:22:50 *	rouffj ( has joined #symfony-dev
Mar 24 12:22:52 <lsmith>	i dont really see much difference between ini and yaml
Mar 24 12:23:11 <fabpot>	and I don't want people to not use Symfony just because the first thing the see is a YAML/XML file
Mar 24 12:23:34 <Stof>	then do all config in ini, not just one of the files :)
Mar 24 12:23:40 <lsmith>	well and what about the people that dont like ini for app config?
Mar 24 12:23:57 <henrikbjorn>	well they can see all formats
Mar 24 12:24:04 <henrikbjorn>	so they know they can choose whatever they want
Mar 24 12:24:13 <everzet>	lsmith: if you know how to configure Symfony2 app in yaml - you will be able to remove this ini simple
Mar 24 12:24:18 <lsmith>	i think adding a 4th format is adding confusion
Mar 24 12:24:27 <fabpot>	I think everybody can understand the goal of a simple ini file, it's just to be able to configure the required settings
Mar 24 12:24:29 <everzet>	lsmith: but if you don't (very begginer) - ini is a good starting point
Mar 24 12:25:02 <everzet>	lsmith: i think it's not about 4th format. It's about single configuration file for beginners.
Mar 24 12:25:06 <pgodel_work>	an explanation would aid in avoiding confusion
Mar 24 12:25:32 <lsmith>	i think our flexibility with formats is a plus
Mar 24 12:25:33 <srohweder>	thfo the beginners you can include one yml and hide the complicated stuff in imports
Mar 24 12:25:38 <Seldaek>	I guess the ini file is ok for standard distro maybe, but shouldn't be there in the others
Mar 24 12:25:41 <ajessu>	I like it for beginners.. it's easy to copy and paste (think tabs vs spaces in yaml) and very easy to understand right away
Mar 24 12:25:43 <lsmith>	but at the same time its confusing as hell for beginners already
Mar 24 12:25:44 <ajessu>	just to get started
Mar 24 12:26:11 <lsmith>	sure an ini file is something they will have seen with their php.ini
Mar 24 12:26:12 <pgodel_work>	but it is confusing because there is no explanantion and it was a suprise for us
Mar 24 12:26:24 <Seldaek>	on the other hand, all the sf1 users are used to yaml..
Mar 24 12:26:31 <everzet>	lsmith: yeah. We need to tell them not to open other *.yml stuff before they'll become mature
Mar 24 12:26:33 <pgodel_work>	but I think it is easily addressable by documeting properly
Mar 24 12:26:34 <lsmith>	anyway ..
Mar 24 12:26:42 <lsmith>	either we vote on it .. or let fabpot decide
Mar 24 12:26:46 <lsmith>	no reason to keep talking about this
Mar 24 12:26:47 <henrikbjorn>	+1
Mar 24 12:26:51 <everzet>	+1
Mar 24 12:26:51 <henrikbjorn>	for ini
Mar 24 12:27:00 <fabpot>	+1
Mar 24 12:27:01 *	old_sound has quit (Quit: old_sound)
Mar 24 12:27:02 <ajessu>	+1
Mar 24 12:27:04 <srohweder>	0
Mar 24 12:27:04 <lsmith>	-1 for .ini
Mar 24 12:27:05 <beberlei>	+1 for ini
Mar 24 12:27:06 <snc_hw>	but then my issue should be fixed
Mar 24 12:27:06 <avalanche123>	+1
Mar 24 12:27:09 <igorw>	-1 for ini
Mar 24 12:27:25 <snc_hw>	escape the "=" in the configurator
Mar 24 12:27:30 <lsmith>	ok voting ending in 10
Mar 24 12:27:39 <lsmith>	5
Mar 24 12:27:53 <lsmith>	0
Mar 24 12:27:56 <lsmith>	ok .. ini stays
Mar 24 12:27:59 <lsmith>	next topic
Mar 24 12:28:02 <lsmith>	"core" dev meeting in Paris:
Mar 24 12:28:17 <lsmith>	basically i tried to remind us of our decisions from paris
Mar 24 12:28:27 *	srohweder has quit (Quit: leaving)
Mar 24 12:28:39 <lsmith>	i guess the "core bundle names" still need to be fixed
Mar 24 12:28:45 <lsmith>	aka we wanted to also prefix them with Symfony
Mar 24 12:28:50 *	ornicar has quit (Quit: WeeChat 0.3.4)
Mar 24 12:28:56 <lsmith>	fabpot: i will open a ticket for this?
Mar 24 12:29:27 <lsmith>	bridges have started to be created .. i guess each person responsible for a bundle/component can take care of that themselves?
Mar 24 12:29:33 <fabpot>	lsmith: but the problem is that everything will be prefixed with symfony_ in config files
Mar 24 12:29:49 <Seldaek>	fabpot: is this really a problem?
Mar 24 12:29:53 <lsmith>	ok .. then lets discuss this
Mar 24 12:29:55 <Seldaek>	it'll look weird for 3 days
Mar 24 12:29:58 <Seldaek>	then we'll be used to it
Mar 24 12:30:02 <jmikola|w>	wasn't kriswallsmith's aliases able to work around that?
Mar 24 12:30:04 <lsmith>	i agree with Seldaek
Mar 24 12:30:20 <jmikola|w>	or were we not going to employ that for the core config stuff
Mar 24 12:30:36 *	Bastor ( has joined #symfony-dev
Mar 24 12:30:37 <fabpot>	I don't see the big deal about keeping the current names for core bundles
Mar 24 12:30:49 <lsmith>	fabpot: its about eating our own standards
Mar 24 12:30:50 <henrikbjorn>	i think the current names should stay
Mar 24 12:31:09 <fabpot>	lsmith: that's already not the case as we have a Bundle\ sub-namespace
Mar 24 12:31:12 <lsmith>	or at least we then should state clearly in our docs that people shouldnt look at the core bundles if they want to follow our "best practices"
Mar 24 12:31:14 <jmikola|w>	is essentially the same as using non-prefixed service id's elsewhere... if core stuff is going to have top-level names w/o prefixes for services, i don't see why not for configs
Mar 24 12:31:15 <henrikbjorn>	lsmith: they are point zero and core to the framework so they dont really belong to anyone
Mar 24 12:31:50 <jmikola|w>	lsmith: perhaps that best practice should start applying for something like FrameworkExtraBundle? instead of the core stuff
Mar 24 12:32:02 <fabpot>	jmikola|w: that's already the case
Mar 24 12:32:15 <lsmith>	alright then .. i will submit something a PR to add to the docs that core Bundles do not follow the best practices
Mar 24 12:32:24 <jmikola|w>	yes; i meant to say that's the line when we start enforcing best practices, not core bundles
Mar 24 12:32:26 <everzet>	:-)
Mar 24 12:32:44 <lsmith>	so bridges each of the maintainers will handle themselves
Mar 24 12:33:00 <lsmith>	missing interfaces should just be filed as tickets or PR's by the person that misses them
Mar 24 12:33:29 <lsmith>	"overwriting bundle parameters" .. i will submit a PR to add to the docs that people shouldnt rely on BC when overriding bundle parameters
Mar 24 12:33:43 <lsmith>	should i create a ticket for removing class parameters?
Mar 24 12:34:03 <Seldaek>	I would say no
Mar 24 12:34:09 *	DolbyDB (~IceChat77@ has joined #symfony-dev
Mar 24 12:34:10 <fabpot>	lsmith: that's also on my TODO list
Mar 24 12:34:14 <Seldaek>	they can stay there as an unsupported extension point for dirty hacks
Mar 24 12:34:14 <lsmith>	k
Mar 24 12:34:22 <Seldaek>	but nobody seems to like that :p
Mar 24 12:34:41 <everzet>	Seldaek: no one likes dirty hacks anymore :-(
Mar 24 12:34:51 <Seldaek>	yeah, that's just no fun. dirty hacks are useful sometimes.
Mar 24 12:34:58 <lsmith>	ok .. that covers all the topics from that list that havent been covered yet
Mar 24 12:35:04 <Seldaek>	everything is private and strict now..
Mar 24 12:35:05 <lsmith>	so next topic .. ok?
Mar 24 12:35:07 <henrikbjorn>	looks like ill need to redefine a lot of services then
Mar 24 12:35:08 <jmikola|w>	Seldaek: we still need dirty hacks for some things :)
Mar 24 12:35:09 <henrikbjorn>	awesome
Mar 24 12:35:13 <johanness>	actually changing the class is less risky than changing the entire service
Mar 24 12:35:47 <lsmith>	Naming collisions with Bundles:,
Mar 24 12:35:50 <lsmith>	kriswallsmith: ?
Mar 24 12:35:54 <Seldaek>	yeah I really don't htink it's a good idea to remove those class params
Mar 24 12:36:14 <everzet>	Seldaek: +1
Mar 24 12:36:15 <kriswallsmith>	i just stepped away, what's up?
Mar 24 12:36:16 <beberlei>	regarding bridges, we will create a doctrine one for form related stuff and move some stuff for twig into the twig one
Mar 24 12:36:16 *	jstout (~jstout@ has joined #symfony-dev
Mar 24 12:36:21 *	dbu has quit (Remote host closed the connection)
Mar 24 12:36:27 <fabpot>	beberlei: thanks
Mar 24 12:36:33 <beberlei>	i had a question about naming bridges that combine two components
Mar 24 12:36:51 <beberlei>	for example the translating helper in Framework Bundle
Mar 24 12:36:54 <lsmith>	kriswallsmith: just wanted to move to the topic of bundle alias's .. but it seems we are not yet ready to
Mar 24 12:37:09 *	jakubzalas ( has joined #symfony-dev
Mar 24 12:37:11 <beberlei>	should we create a Symfony\Bridge\TemplatingTranslation ?
Mar 24 12:37:16 <beberlei>	or how should that be handled
Mar 24 12:37:19 <kriswallsmith>	i think class names should remain as parameters
Mar 24 12:37:45 <lsmith>	ok .. so does everybody understand the topic if class parameter removal? if so we can have a quick vote
Mar 24 12:37:52 <jmikola|w>	kriswallsmith: perhaps at least for public services? or privates as well
Mar 24 12:38:08 <fabpot>	beberlei: bridges are for third-party libraries only
Mar 24 12:38:10 <henrikbjorn>	-1 for removing
Mar 24 12:38:18 <fabpot>	-1
Mar 24 12:38:21 <everzet>	-1
Mar 24 12:38:21 <avalanche123>	-1
Mar 24 12:38:30 <kriswallsmith>	-1 for removing
Mar 24 12:38:30 *	igorw_ ( has joined #symfony-dev
Mar 24 12:38:31 *	igorw_ has quit (Changing host)
Mar 24 12:38:31 *	igorw_ (~igorw@phpbb/developer/evil3) has joined #symfony-dev
Mar 24 12:38:35 <Seldaek>	+1 for dirty hacks
Mar 24 12:38:40 <kriswallsmith>	heh
Mar 24 12:38:41 <everzet>	Seldaek: :-D
Mar 24 12:38:49 <beberlei>	fabpot: so how should we handle the translation helper? it seems to me that its wrongly placed in framework bundle
Mar 24 12:38:51 <lsmith>	i know bschussek was -1 (aka removing) .. i am +0
Mar 24 12:38:54 <jmikola|w>	-1, unless we go all out for configs that make it easier to avoid dirty hacks
Mar 24 12:39:08 <lsmith>	kriswallsmith: are you sure you voted like you intended?
Mar 24 12:39:08 <henrikbjorn>	to be honost a lot of flexibilty is gone if class params are removed
Mar 24 12:39:20 <lsmith>	ah no
Mar 24 12:39:23 <lsmith>	i am confused
Mar 24 12:39:24 *	ornicar (~ornicar@ has joined #symfony-dev
Mar 24 12:39:28 <beberlei>	i am against removal
Mar 24 12:39:31 <fabpot>	beberlei: I will have a look at this specific example
Mar 24 12:39:31 <beberlei>	if that is -1
Mar 24 12:39:35 <lsmith>	so -1 is not removing the class parameters
Mar 24 12:39:38 <fabpot>	yes
Mar 24 12:39:40 <avalanche123>	yes
Mar 24 12:39:41 <jmikola|w>	i thought it was
Mar 24 12:39:42 *	johnwards ( has joined #symfony-dev
Mar 24 12:39:44 <everzet>	yep
Mar 24 12:39:46 <beberlei>	lol
Mar 24 12:39:46 <fabpot>	so, basically nobody want to remove them
Mar 24 12:39:48 <lsmith>	ok .. so they will stay ..
Mar 24 12:39:50 <avalanche123>	yes
Mar 24 12:39:54 <jmikola|w>	great success!
Mar 24 12:39:55 <lsmith>	good
Mar 24 12:39:58 <lsmith>	now moving on
Mar 24 12:39:58 <henrikbjorn>	awesome
Mar 24 12:39:59 <henrikbjorn>	:p
Mar 24 12:40:00 <avalanche123>	unity
Mar 24 12:40:01 <lsmith>	Naming collisions with Bundles:,
Mar 24 12:40:02 *	igorw has quit (Ping timeout: 276 seconds)
Mar 24 12:40:03 *	igorw_ is now known as igorw
Mar 24 12:40:05 <lsmith>	kriswallsmith: take it away :)
Mar 24 12:40:29 <lsmith>	or fabpot .. i saw you have made up your mind
Mar 24 12:40:46 <lsmith>	or lets say the topic is many fold
Mar 24 12:41:09 <lsmith>	i think one is about in general us not enforcing namespacing of services etc in Bundles
Mar 24 12:41:20 <lsmith>	the other is kriswallsmith's PR about Bundle alias's
Mar 24 12:41:22 *	kris|m ( has joined #symfony-dev
Mar 24 12:41:58 <lsmith>	imho not enforcing namespacing for services and the likes is ok .. we just have to document it as part of the best practices
Mar 24 12:42:17 <fabpot>	lsmith: I don't understand why we would want to enforce namespaces for services
Mar 24 12:42:24 <lsmith>	fabpot: neither do i
Mar 24 12:42:25 <beberlei>	hm, every implementator has the right to claim the default namespace for himself
Mar 24 12:42:39 <beberlei>	so "request", "router" as a service is very nice imho
Mar 24 12:42:54 <beberlei>	namespacing third party bundle services should be done though
Mar 24 12:42:58 *	IfSixWasNine has quit (Quit: IfSixWasNine)
Mar 24 12:42:59 <beberlei>	as a best practice
Mar 24 12:43:06 <beberlei>	am i talking on the right topic?
Mar 24 12:43:08 <beberlei>	:p
Mar 24 12:43:12 <lsmith>	beberlei: yes .. by documentation .. not by force
Mar 24 12:43:24 <lsmith>	so the other side of the topic is
Mar 24 12:43:32 <lsmith>	aka "Bundle (and extension) aliases"
Mar 24 12:43:39 <lsmith>	which is kriswallsmith's pull .. but he seems to be afk?
Mar 24 12:44:04 *	kris|m has quit (Client Quit)
Mar 24 12:44:15 <lsmith>	from fabpot's last comment .. it sounds like either we shouldnt add the feature at all
Mar 24 12:44:21 <fabpot>	I'm -1 as it introduces yet another way to reference a bundle
Mar 24 12:44:35 <kriswallsmith>	I'm here
Mar 24 12:44:46 <lsmith>	or at least only offer it as a "use at your own risk" for peoples own application bundles
Mar 24 12:44:51 <Seldaek>	I think if it's merged, then the @-magic should go away so it's either FQCN, or alias
Mar 24 12:45:06 <rande>	me too ;) I will prefer to remove the 'Bundle' keyword
Mar 24 12:45:12 <Seldaek>	but the fact that it's defined outside of the bundle is a bit nasty
Mar 24 12:45:37 <kriswallsmith>	Seldaek: that's the whole point
Mar 24 12:45:49 <kriswallsmith>	I'm ok with closing the PR
Mar 24 12:45:59 <Seldaek>	of course, if we called Bundles "Zs" instead of Bundles, then it'd be easier to type BlogZ:Post:blah.html.twig
Mar 24 12:46:00 *	henrikbjorn has quit (Ping timeout: 276 seconds)
Mar 24 12:46:06 <fabpot>	rande: we can remove 
the Bundle suffix, that's a valid proposal
Mar 24 12:46:07 <kriswallsmith>	if people don't like it
Mar 24 12:46:08 *	henrikbjorn ( has joined #symfony-dev
Mar 24 12:46:10 <Seldaek>	+1s on Zs? :/
Mar 24 12:46:12 *	henrikbjorn has quit (Remote host closed the connection)
Mar 24 12:46:27 <everzet>	fabpot: oh. That's interesting
Mar 24 12:46:34 <Seldaek>	fabpot: seriously? I don't know how many times I've bitched about the Bundle suffix
Mar 24 12:46:44 <Seldaek>	that'd be awesome
Mar 24 12:46:49 <everzet>	Seldaek: +1
Mar 24 12:46:52 <avalanche123>	Bundle\Bundle\BundleBundle
Mar 24 12:47:19 <fabpot>	avalanche123: so, you work for the Bundle company now? that's a problem for sure ;)
Mar 24 12:47:23 <Seldaek>	Symfony\Bundle\Framework\FrameworkBundle / Liip\View\ViewBundle
Mar 24 12:47:24 <avalanche123>	:)
Mar 24 12:47:35 <everzet>	Behat\Bundle\BehatBundle
Mar 24 12:47:39 <avalanche123>	fabpot, indeed, we make Bundles
Mar 24 12:47:40 <Seldaek>	that'd be nicer already, and especially View:Foo:bar would be much nicer
Mar 24 12:47:45 <fabpot>	Liip\View\ViewBundle should be Liip\View\LiipViewBundle
Mar 24 12:47:52 <Seldaek>	fabpot: yeah sorry
Mar 24 12:47:56 <fabpot>	so LiipView:For:Bar
Mar 24 12:47:57 <avalanche123>	oh
Mar 24 12:48:02 <avalanche123>	so Bundle\Bundle\BundleBundleBundle
Mar 24 12:48:09 <jstout>	avalanche123: haha
Mar 24 12:48:42 <avalanche123>	:)
Mar 24 12:48:43 <lsmith>	ok why didnt we change this before?
Mar 24 12:48:50 <lsmith>	because i remember that we talked about it
Mar 24 12:49:01 <avalanche123>	it wasn't that obvious I think
Mar 24 12:49:05 <Seldaek>	afaik, everytime I ranted, it was said that it was confusing that the directory wasn't called *Bundle
Mar 24 12:49:14 <avalanche123>	and it alse made sense, we have *Controller classes
Mar 24 12:49:15 <everzet>	lsmith: because there was no Bundle\Bundle\BundleBundleBundle
Mar 24 12:49:31 <Seldaek>	but on the other hand, it makes the code feel symfony specific because it is called bundle, while it's really not that specific
Mar 24 12:49:36 <kriswallsmith>	we can just lob Bundle off the name
Mar 24 12:49:38 <Seldaek>	so it's better without *Bundle imo
Mar 24 12:49:47 <Seldaek>	we might even argue we don't need bridges anymore ;)
Mar 24 12:49:58 <kriswallsmith>	no need to change the class name or ns
Mar 24 12:49:59 <jmikola|w>	so Bundle only goes in the namespace component, or it's completely optional? i was also afk
Mar 24 12:50:14 <fabpot>	Just to be clear, I propose to remove the Bundle suffix in the shortcut notation, I do not propose to rename the bundle class
Mar 24 12:50:20 <everzet>	I think we don't need Bundle in actual bundle name as we already have it in NS
Mar 24 12:50:23 <lsmith>	fabpot: ah :)
Mar 24 12:50:27 <avalanche123>	fabpot understood that and +1
Mar 24 12:50:30 <jmikola|w>	fabpot: that certainly makes sense
Mar 24 12:50:30 <beberlei>	fabpot: +1
Mar 24 12:50:34 <kriswallsmith>	fabpot: +1
Mar 24 12:50:36 <lsmith>	thats what i also understood initially .. but people confused me
Mar 24 12:50:41 <Seldaek>	fabpot: ok, that's only 0.5x as awesome, but it's still a great change
Mar 24 12:50:44 <Stof>	fabpot: +1
Mar 24 12:50:48 <jstout>	fabpot: +1 !
Mar 24 12:50:48 <lsmith>	+1
Mar 24 12:50:55 <everzet>	+0.5
Mar 24 12:51:01 <fabpot>	ok, who wants to work on the patch?
Mar 24 12:51:12 <johanness>	can there be conflicts if we remove this?
Mar 24 12:51:24 <Seldaek>	no, bundle was mandatory afaik
Mar 24 12:51:36 <jmikola|w>	beberlei: when we call getRepository with something like MainBundle:User and it translates to Vendor/MainBundle/Entity/User, is that magic inside doctrine bundle?
Mar 24 12:51:38 <lsmith>	i volunteer Seldaek :)
Mar 24 12:51:54 <Seldaek>	lsmith: well, I would, but I have beer waiting for me. I can try to do it this weekend though
Mar 24 12:51:57 <jmikola|w>	johanness: i don't think there will be conflicts, as it's just removing "Bundle" suffix across the board
Mar 24 12:52:01 <beberlei>	jmikola: yes, its called Entity Namespace Alias
Mar 24 12:52:06 bantu Bastor beberlei BeryWork bobthecow bshafs 
Mar 24 12:52:12 <kriswallsmith>	I'll do the patch
Mar 24 12:52:13 <jmikola|w>	beberlei: and those are configured from the config mapping block?
Mar 24 12:52:19 <lsmith>	ok .. then last topic
Mar 24 12:52:20 <lsmith>	Cache warming:,
Mar 24 12:52:23 <lsmith>	kriswallsmith: thx!
Mar 24 12:52:23 <beberlei>	jmikola|w yes
Mar 24 12:52:30 <lsmith>	is there still something to be done where?
Mar 24 12:52:38 <lsmith>	s/where/there
Mar 24 12:52:43 <Stof>	jmikola|w: Doctrine allows to define an alias for a namespace. Then DoctrineBundle define it by default for bundles and you can change them
Mar 24 12:52:48 <Seldaek>	kriswallsmith: great
Mar 24 12:52:59 <fabpot>	lsmith: yes, I have not had time to have a look at it
Mar 24 12:53:03 *	chirimoya has quit (Quit: Linkinus -
Mar 24 12:53:17 <beberlei>	Stof: you can change them, there is a parameter ofr it
Mar 24 12:53:29 <beberlei>	was it removed?
Mar 24 12:53:34 <lsmith>	is there someone else with sufficient deep understanding of all the issues that could discuss this with you fabpot to take it off your hands?
Mar 24 12:53:35 <Stof>	beberlei: I just said it
Mar 24 12:53:36 <kriswallsmith>	beberlei: can you update D bundles with the alias change?
Mar 24 12:53:40 *	tystr (~tylerstro@ has joined #symfony-dev
Mar 24 12:53:51 <Seldaek>	just one quick question if we are out of topics.. what's with the form component? should we schedule a meeting this weekend? should we all try to have a look at it? Can someone do a PoC bundle we could look at to get a feel how it works?
Mar 24 12:53:52 <fabpot>	lsmith: I just have a feeling, no hard facts
Mar 24 12:53:53 <beberlei>	just remove the *BUndle or what?
Mar 24 12:53:53 <Stof>	kriswallsmith: I will do that
Mar 24 12:54:05 <kriswallsmith>	Stof: thanks
Mar 24 12:54:15 <kriswallsmith>	beberlei: exactly
Mar 24 12:54:35 <avalanche123>	I wanted to discuss mongodb session storage and where you think it makes sense to put it
Mar 24 12:54:59 <avalanche123>	I have it implemented and working and we don't want to put it into http foundation
Mar 24 12:55:05 <avalanche123>	but it doesn't rely on doctrine
Mar 24 12:55:07 <beberlei>	bridge
Mar 24 12:55:13 <avalanche123>	and uses raw Mongo class
Mar 24 12:55:26 <avalanche123>	beberlei, how does it work?
Mar 24 12:55:29 <jstout>	I'm with Saldaek on the forms.
Mar 24 12:55:48 <johanness>	avalanche123, why don't you want to put it into http foundation?
Mar 24 12:55:53 <fabpot>	beberlei: no, it's not a bridge as their is no third-party lib
Mar 24 12:56:02 <fabpot>	johanness: because I don't want to
Mar 24 12:56:02 <lsmith>	beberlei: so the PR didnt happen today .. will it happen tomorrow?
Mar 24 12:56:04 <beberlei>	pecl/mongodb is sort of third party :D
Mar 24 12:56:06 <johanness>	:)
Mar 24 12:56:07 <jmikola|w>	avalanche123: is there a memcache driver in core?
Mar 24 12:56:18 <avalanche123>	jmikola|w, not necessary
Mar 24 12:56:24 <beberlei>	lsmith: bschussek will be back at 9, there are small details that need to be worked on, the PR will be tonight or tomorrow
Mar 24 12:56:30 <lsmith>	ok
Mar 24 12:56:30 <avalanche123>	you just configure memcache with session support when compiling php
Mar 24 12:56:36 <avalanche123>	jmikola|w ^
Mar 24 12:56:37 <mvrhov>	regarding the experimental forms. Rendering is broken currently so I've converted one form class to new syntax, but got stuck there.
Mar 24 12:56:40 <lsmith>	so i think we need at least 24 hours to review the PR
Mar 24 12:56:47 <lsmith>	before it makes sense to take a decision
Mar 24 12:56:48 <Seldaek>	jmikola|w: it's not about core/thirdparty, it's about what we want to support in Sf-core I think
Mar 24 12:56:52 *	guilhermeblanco (~quassel@nat/yahoo/x-hoarhdgilokaksdg) has joined #symfony-dev
Mar 24 12:57:05 <lsmith>	should we do an IRC meeting to discuss the last questions and vote on the weekend?
Mar 24 12:57:07 <avalanche123>	Seldaek right
Mar 24 12:57:09 <beberlei>	there will also be an Acme Bundle on the Forms
Mar 24 12:57:18 <lsmith>	beberlei: great
Mar 24 12:57:23 <beberlei>	so that everyone can see some use.cases, i am working on that tonight
Mar 24 12:57:28 <fabpot>	lsmith: I will definitely need more than 24 hours
Mar 24 12:57:31 <avalanche123>	so beberlei, HttpFoundationMongoBridge?
Mar 24 12:57:35 <jmikola|w>	Seldaek: i was just considering if there was a problem conditionally supporting pecl extensions in core
Mar 24 12:57:42 <lsmith>	ok .. so then a meetin on monday?
Mar 24 12:57:46 <Seldaek>	jmikola|w: the question is, if we move it in core, can we trust avalanche123 to maintain it or will he try to make a run for the mexican border at the first occasion?
Mar 24 12:57:46 <lsmith>	or wait until next thursday
Mar 24 12:58:04 <jmikola|w>	Seldaek: Mongo doesn't really seem common enough to be in core, but i don't see harm in having the code there - it simply wouldn't get loaded if people don't use it
Mar 24 12:58:05 <lsmith>	or only schedule a meeting if we feel we need one
Mar 24 12:58:20 <lsmith>	otherwise just handle it via PR comments and mailinglist
Mar 24 12:58:22 <jmikola|w>	Seldaek: Bulat legally can't cross any other borders, so we're good
Mar 24 12:58:27 <avalanche123>	Seldaek, you can trust me ;)
Mar 24 12:58:31 <fabpot>	lsmith: yes, let's discuss everything on the ML
Mar 24 12:58:35 <lsmith>	ok
Mar 24 12:58:38 <avalanche123>	jmikola|w haha
Mar 24 12:58:40 *	henrikbjorn ( has joined #symfony-dev
Mar 24 12:58:41 <lsmith>	so then meeting done