You must first sign up to be able to contribute.

Version 1 (modified by lsmith, 7 years ago)


IRC logs

Jan 20 10:59:38 <henrikbjorn>	lsmith?
Jan 20 11:01:05 <Seldaek>	he's sitting beside me
Jan 20 11:01:16 <Seldaek>	let me ping
Jan 20 11:01:57 <lsmith>	ah
Jan 20 11:02:02 <lsmith>	well lets go and stuff
Jan 20 11:02:04 <pgodel_work>	did he fall asleep ? :)
Jan 20 11:02:13 <Seldaek>	nah he was lost in code
Jan 20 11:02:16 <lsmith>	some people have to do real work ... like refactoring unit tests
Jan 20 11:02:23 <pgodel_work>	:)
Jan 20 11:02:27 <lsmith>	so Template names:
Jan 20 11:02:31 <lsmith>	fight!
Jan 20 11:02:49 <Seldaek>	ok, soo.. anyone doesn't have a clear vision of the problem?
Jan 20 11:03:05 <Seldaek>	basically I think having the format at the end is awful for IDEs/syntax highlighting
Jan 20 11:03:21 <Seldaek>	and it'll bite us in the ass in the long term with all the people that'll be confused
Jan 20 11:03:27 <fabpot>	the format and the renderer are the same as far as the IDE is concernted
Jan 20 11:03:35 <naderman>	I think it's good for IDEs/syntax highlighting, because editors that don't know twig won't highlight it at all otherwise
Jan 20 11:03:45 <henrikbjorn>	I agree and fileextensions should identify what type of file it is
Jan 20 11:03:45 <fabpot>	so, a template is about two things: Twig and HTML, or JS and PHP, ...
Jan 20 11:03:54 <Seldaek>	fabpot: the ide just sees a file extension
Jan 20 11:03:55 <jmikola|w>	I think Seldaek posted the example of .twig.html conflicting with .html rules
Jan 20 11:03:56 <fabpot>	so, we need to base our decision based on IDEs behaviors
Jan 20 11:04:10 <pgodel_work>	I like Fabien short summary: "For me, an HTML template is about
Jan 20 11:04:10 <pgodel_work>	a lot of HTML a a few Twig tags. So, the "main" format is definitely HTML. "
Jan 20 11:04:32 <jmikola|w>	also, i know the smarter editors like eclipse will run through .twig.php or .twig.html files and actually consider the files invalid because of intermixed twig syntax
Jan 20 11:04:43 <henrikbjorn>	Fabpot but the files are not html/js they are twig files
Jan 20 11:04:46 <jmikola|w>	not a problem for things like TextMate that just do syntax highlighting, of course
Jan 20 11:04:46 <Seldaek>	fabpot: IDEs can mostly be configured to handle .twig file as .php file, or .html, or .tpl (so they have smarty like highlighting), but you can't tell most IDEs to use .twig.* as a match I think
Jan 20 11:05:04 <henrikbjorn>	No matter in what degree they contain twig tags
Jan 20 11:05:13 <jmikola|w>	Seldaek: I think folks would even want to use .html.twig as html rules, and .php.twig as php rules
Jan 20 11:05:21 *	mpiecko ( has joined #symfony-dev
Jan 20 11:05:26 <fabpot>	Seldaek: the question is: for dumb IDEs that can hightlight both Twig and HTML, which one is better: HTML or Twig?
Jan 20 11:05:26 <jmikola|w>	which should be very simple, since there likely won't be a generic .twig rule to conflict with
Jan 20 11:05:29 <Seldaek>	jmikola|w: well, that's a nice to have sure
Jan 20 11:05:33 <henrikbjorn>	You dont open a jpg file and expect php code
Jan 20 11:05:37 <Seldaek>	fabpot: imo twig
Jan 20 11:05:40 <avalanche123>	what was the default smarty naming convention? .html.tpl or .tpl.html?
Jan 20 11:05:40 <cranberyxl>	henrikbjorn: +1
Jan 20 11:05:56 <jmikola|w>	i believe smarty ends with .tpl, but it's been a while :)
Jan 20 11:06:01 <Seldaek>	fabpot: because html is html, they might support php in it, but if they support twig highlighting they'll support .twig
Jan 20 11:06:03 <henrikbjorn>	Smarty is tpl at the end
Jan 20 11:06:10 <pgodel_work>	you really care about smarty ? ;)
Jan 20 11:06:15 <avalanche123>	doesn't matter how long its been, I think its expected
Jan 20 11:06:22 <pgodel_work>	yeah, tpl
Jan 20 11:06:32 <Seldaek>	avalanche123: it's JUST .tpl, there is no freaking .html in there
Jan 20 11:06:32 <jmikola|w>	avalanche123: i meant it's been a while since i worked with it :)
Jan 20 11:06:45 <fabpot>	so, my personal opinion is that I don't really care. We just need to take a decision and be done with it
Jan 20 11:06:49 <avalanche123>	Seldaek, gotcha
Jan 20 11:06:53 <avalanche123>	fabpot +1
Jan 20 11:07:01 <naderman>	agreed
Jan 20 11:07:02 <lsmith>	i dont care either
Jan 20 11:07:08 <henrikbjorn>	I care :)
Jan 20 11:07:13 <fabpot>	so, the ones who care, speak up!
Jan 20 11:07:19 <avalanche123>	so let's vote then. who's for .html?
Jan 20 11:07:26 <Seldaek>	imo it's simple, file extension defines the content, which in this case the main content is the renderer stuff
Jan 20 11:07:40 <Seldaek>	the rest is added symfony specific meaning
Jan 20 11:07:44 <pgodel_work>	Seldaek: +1
Jan 20 11:07:44 <jmikola|w>	i'm for .twig, even though i really don't want to rename all of our templates again
Jan 20 11:07:46 <Seldaek>	if IDEs decide to support it down the line, great
Jan 20 11:07:49 <Seldaek>	but most won't
Jan 20 11:07:56 <henrikbjorn>	Seldaek exactly
Jan 20 11:07:56 <Stof>	Seldaek: +1
Jan 20 11:08:00 <cranberyxl>	.twig
Jan 20 11:08:02 <everzet>	.twig
Jan 20 11:08:07 <beberlei>	at least IDEs that dont detect a file extension support to add a renderer for it
Jan 20 11:08:13 <henrikbjorn>	Ill gladly do the back porting
Jan 20 11:08:14 <Stof>	.twig
Jan 20 11:08:14 <beberlei>	so you can say in netbeans render .twig as html
Jan 20 11:08:16 <tecbot>	.twig
Jan 20 11:08:20 <mvrhov>	hm I just tired in eclipse *.twihg.html is nogo
Jan 20 11:08:28 <mvrhov>	*.twig.html
Jan 20 11:08:35 <Seldaek>	so.. rename?
Jan 20 11:08:37 <beberlei>	but .twig means .html.twig yah?
Jan 20 11:08:40 <Seldaek>	yes
Jan 20 11:08:42 <everzet>	yep
Jan 20 11:08:42 <Stof>	yes
Jan 20 11:08:43 <henrikbjorn>	Yes
Jan 20 11:08:45 <avalanche123>	beberlei yeah
Jan 20 11:08:49 <Seldaek>	lsmith: next:)
Jan 20 11:09:01 <fabpot>	beberlei: but Twig can be used for HTML, or JS, or anything really. So, to have a good hightlighting, you need an IDE that can do that for Twig AND something else
Jan 20 11:09:06 <lsmith>	Package / Dependency Management for Bundles:
Jan 20 11:09:06 <henrikbjorn>	Ill do it then and finish the pull request
Jan 20 11:09:16 <lsmith>	sorry .. i am a bit busy today ..
Jan 20 11:09:28 <Seldaek>	fabpot: most will default to html+twig, if they support twig at all, then some might get smarter for symfony specific users I guess
Jan 20 11:09:43 <Seldaek>	fabpot: but that's the main use case so I think it's ok
Jan 20 11:09:49 <beberlei>	well having .xml.twig and .html.twig, wwhat do you highlight?
Jan 20 11:09:51 <Seldaek>	and definitely better than no highlighting at all
Jan 20 11:10:00 <bobthecow>	for what it's worth, Coda and SubEthaEdit highlight .twig files.
Jan 20 11:10:05 <jmikola|w>	regarding the dep management, fabpot is there any progress from talking to Brett about Pyrus?
Jan 20 11:10:05 <henrikbjorn>	Beberlei twig
Jan 20 11:10:15 <bobthecow>	.xml.twig is a superset of .xml
Jan 20 11:10:18 <Seldaek>	beberlei: twig tags.. but *.twig files will be seen as html+twig tags
Jan 20 11:10:21 <bobthecow>	.html.twig is a superset of html
Jan 20 11:10:22 <fabpot>	jmikola|w: I was not the one who talked with Pyrus guys
Jan 20 11:10:25 <bobthecow>	should highlight both.
Jan 20 11:10:43 <fabpot>	to sum up my point of view on this topic
Jan 20 11:10:45 <beberlei>	basically both nadermann and me found that pyrus is a piece of garbage
Jan 20 11:11:09 <fabpot>	beberlei: hehe, I would not say that... I mean not in public ;)
Jan 20 11:11:11 <beberlei>	we have to write our pirum for the client side that uses a package.xml  which is extended using a new xml namespace
Jan 20 11:11:29 <lsmith>	i guess now with getParent(), we have linear "dependencies"
Jan 20 11:11:30 <fabpot>	there is really 2 things to cover
Jan 20 11:11:45 <naderman>	well pyrus is not meant to be extensible, and it's written in that way, there are quite a few things that would be nice for Symfony that will be very hard to get into there
Jan 20 11:11:54 <fabpot>	lsmith: yes, but dependencies is also about other libraries like Doctrine, or even jQuery
Jan 20 11:12:14 <lsmith>	fabpot: yeah .. not saying its solved by any means
Jan 20 11:12:18 <beberlei>	fabpot: i will state so publically because i feel i have reviewed the code enough and other people might support me in this
Jan 20 11:12:21 <henrikbjorn>	I think we should focus on backend dependencies
Jan 20 11:12:26 <everzet>	naderman: multiversioning for example ;-)
Jan 20 11:12:26 <naderman>	for other libraries it would be nice to have an installer that can speak regular pear package.xml and maybe even more formats
Jan 20 11:12:36 <Stof>	and you can need FOSUB without overwriting it
Jan 20 11:12:37 <Seldaek>	lsmith: getParent() is NOT defining dependencies at all
Jan 20 11:12:46 <fabpot>	ok, I think it won"t be easy to talk about that here
Jan 20 11:12:48 <Seldaek>	it defines what a bundle overrides
Jan 20 11:13:01 *	bschussek (~yaaic@ has joined #symfony-dev
Jan 20 11:13:14 <fabpot>	As naderman seems really interested by the topic, I propose that we talk together and report on the dev mailing-list for further discussions
Jan 20 11:13:25 <beberlei>	yes that would be great
Jan 20 11:13:27 <Seldaek>	fine by me
Jan 20 11:13:29 <beberlei>	we need a start somewhere
Jan 20 11:13:30 *	lapistano has quit (Excess Flood)
Jan 20 11:13:36 <avalanche123>	+1
Jan 20 11:13:40 <everzet>	+1
Jan 20 11:13:42 <naderman>	fine by me, missed your message this morning btw, sorry
Jan 20 11:13:44 <henrikbjorn>	+1
Jan 20 11:13:50 *	lapistano ( has joined #symfony-dev
Jan 20 11:13:52 <Stof>	+1
Jan 20 11:14:00 <avalanche123>	next:)
Jan 20 11:14:02 <Herzult>	ok, we'll wait for it
Jan 20 11:14:17 *	wSuFF has quit (Disconnected by services)
Jan 20 11:14:26 <Seldaek>	damn it lsmith :p
Jan 20 11:14:36 <lsmith>	refactored bundle management:
Jan 20 11:14:49 <everzet>	love it
Jan 20 11:14:50 <pgodel_work>	github down
Jan 20 11:14:57 <lsmith>	sweet
Jan 20 11:15:02 <lsmith>	so lets get back to that one later
Jan 20 11:15:03 <avalanche123>	I opened it up
Jan 20 11:15:05 <naderman>	so topic is unicorns
Jan 20 11:15:06 <Seldaek>	well, I think we know what it is?
Jan 20 11:15:06 <everzet>	angry unicorn is great
Jan 20 11:15:06 <pgodel_work>	refresh worked
Jan 20 11:15:12 <lsmith>	ah ok
Jan 20 11:15:14 *	devilp ( has joined #symfony-dev
Jan 20 11:15:16 <avalanche123>	refresh...
Jan 20 11:15:17 <cranberyxl>	unicorns fart rainbows
Jan 20 11:15:18 <lsmith>	so lets keep going .. fabpot ..
Jan 20 11:15:21 <henrikbjorn>	We need to define best practices and reflect them in init:bundle
Jan 20 11:15:42 <beberlei>	i guess we agree that the bundle refactoring is great, i just feel that around the best practices there is much discussion, like Bundle in class name and such
Jan 20 11:16:01 <jmikola|w>	beberlei: yes, there was some mailing list discussion about this within the last day i think
Jan 20 11:16:03 <fabpot>	yeah, I think that we are now free to dicuss the naming conventions again
Jan 20 11:16:03 *	rande ( has left #symfony-dev
Jan 20 11:16:14 <fabpot>	I can send a new topic about that now
Jan 20 11:16:22 <Seldaek>	two things I wonder fabpot about that: what does the resolving rules look like when you fetch an asset now, and why Vendor\Bundle\Foo*Bundle*\FooBundle
Jan 20 11:16:41 <fabpot>	for assets, it's exactly as before
Jan 20 11:16:43 <beberlei>	but since with the refactoring you actually could serve several bundles from one directory i say having "VendorCategoryNameBundle" as Bundle class is actually a very good decision
Jan 20 11:16:51 <naderman>	fabpot: will you adjust the sandbox autoload.php to have /vendor/ or /src/ as fallbacks?
Jan 20 11:16:54 <Seldaek>	ok, so you refer to bundles by their getName() value
Jan 20 11:17:15 <jmikola|w>	if Vendor is part of the bundle name, and end user bundles sit alongside vendor bundles, it wasn't clear to me how we can override another bundle
Jan 20 11:17:23 <fabpot>	naderman: quite possible, yes
Jan 20 11:17:32 <fabpot>	Seldaek: the getName() method is gone
Jan 20 11:17:34 <beberlei>	jmikola|w: fabien committed a "getParent()" approach for that just now
Jan 20 11:17:41 <fabpot>	the name is just the short class name
Jan 20 11:17:43 <naderman>	I think it's still unclear if people are going to put their 3rd party bundles in /vendor/ but I guess that's down to package management to a degree
Jan 20 11:17:52 <Seldaek>	jmikola|w: yeah that's my question too, I think to override you gotta use the shortname of your class that returns a getParent() from the bundle you wanna override
Jan 20 11:17:59 <fabpot>	naderman: yes, and Symfony2 does not really care
Jan 20 11:18:07 <jmikola|w>	beberlei: but would my App's version of the bundle i override be named FOSUserBundle? (for instance?)
Jan 20 11:18:15 <jmikola|w>	even though it's not in the FOS namespace but my own?
Jan 20 11:18:35 <beberlei>	jmikola|w: no your app is named as you want, "MyAppBundle" and it has a getParent() that says FOSUserBundle
Jan 20 11:18:37 <jmikola|w>	naderman: ah, i didn't catch that third-party bundles go in /vendor
Jan 20 11:19:00 <beberlei>	fabpot: what you cant do with the 1:1 parent->child approach is having one big application bundle that overrites several bundles
Jan 20 11:19:01 <jmikola|w>	i thought /vendor was just for "component" libs... and all bundles (even submodules from third-parties) are in src/
Jan 20 11:19:03 <Seldaek>	jmikola|w: it's up to you, but it doesn't really matter, they go anywhere now that there is no more bundle dirs
Jan 20 11:19:07 <naderman>	jmikola|w: re: naming your bundle FOSUserBundle, no why would you? you just return 'FOSUserBundle' in getParent()
Jan 20 11:19:16 <jmikola|w>	naderman: got it
Jan 20 11:19:30 <fabpot>	beberlei: support is possible
Jan 20 11:19:31 <naderman>	jmikola|w: it's been in discussion on the mailinglist for a bit recently
Jan 20 11:19:42 <fabpot>	beberlei: getParent() can just return an array of parents
Jan 20 11:19:52 <fabpot>	beberlei: that's easy to implement, but do we want that?
Jan 20 11:20:09 <naderman>	jmikola|w: the question was whether there was a point in keeping 3rd party Bundles somewhere other than libraries
Jan 20 11:20:10 <beberlei>	not sure, but people are going to ask why they cant to do it
Jan 20 11:20:12 <Seldaek>	fabpot: but then, you do @AppBundle/Resources/.., and the code checks if it's in appbundle, and then if not it has to check all the parents?
Jan 20 11:20:19 *	henrikbjorn has quit (Ping timeout: 276 seconds)
Jan 20 11:20:23 <avalanche123>	hmm, I know I might get killed for this, but what if we registered view names in DIC as parameters and refered to them by parameter key, that would me it overridable on parameter level?
Jan 20 11:20:24 <jmikola|w>	beberlei: are you concerned about overhead of creating bundles to override one resource at a time?
Jan 20 11:20:27 <Seldaek>	fabpot: that seems not to be an improvement in performances compared to the bundle dir approach
Jan 20 11:20:29 <beberlei>	Seldaek: inheritanc eonly works the other way around
Jan 20 11:20:37 <fabpot>	Seldaek: performance is better now
Jan 20 11:20:42 <avalanche123>	then I could define App:Controller:view.twig parameter with wome other value
Jan 20 11:20:46 <avalanche123>	*with
Jan 20 11:20:48 *	henrikbjorn ( has joined #symfony-dev
Jan 20 11:20:50 <Seldaek>	fabpot: so if you wanna override a bundle you have to copy ALL assets from it?
Jan 20 11:20:53 *	wSuFF_ (~wsuff@ has joined #symfony-dev
Jan 20 11:20:57 *	jmikola|w kills avalanche123
Jan 20 11:21:01 <fabpot>	Seldaek: no, just the one you want to override
Jan 20 11:21:10 <fabpot>	it's exactly like what we have today
Jan 20 11:21:13 <Seldaek>	fabpot: yeah, otherwise it falls back to the parent path, taht's what I'm saying
Jan 20 11:21:23 <lsmith>	which fyi doesnt work for symlink
Jan 20 11:21:23 <Seldaek>	but if you do multiple inheritance, you'd have to check many parent paths
Jan 20 11:21:27 <naderman>	so if you have multiple paths it's not just "fallback"
Jan 20 11:21:27 <Seldaek>	so it'd become very slow
Jan 20 11:21:40 <naderman>	*multipl eparents
Jan 20 11:21:43 <fabpot>	Seldaek: but most of the time, you just have one parent and one child
Jan 20 11:21:55 <fabpot>	I don't see why you would want several parents
Jan 20 11:22:04 <fabpot>	you get a third-party bundle and you extend it
Jan 20 11:22:06 <Seldaek>	fabpot: well, I don't know "most of the time" based on what? I could see an app bundle wanting to override many bundles it uses
Jan 20 11:22:13 <beberlei>	what is the convention for overriding bundles now btw? if we have 1:1 inheritance would you name it MyFOSUserBundle ?
Jan 20 11:22:27 <beberlei>	AppFOSUserBundle?
Jan 20 11:22:29 <lsmith>	beberlei: it has a different vendor namespace
Jan 20 11:22:33 <fabpot>	beberlei: each bundle must have a different and unique name
Jan 20 11:22:38 <Stof>	what would be the way to get an overrided template ? the child name or the parent name ?
Jan 20 11:22:40 <Seldaek>	beberlei: you name it AppUserBundle and return FOSUserBundle in getParent
Jan 20 11:22:42 <fabpot>	name == short class name
Jan 20 11:22:46 <beberlei>	ah yeah probably
Jan 20 11:22:47 <lsmith>	src/FOS/UserBundle src/MyVendorNS/UserBundle
Jan 20 11:22:57 <jmikola|w>	avalanche123: in all seriousness view names as DIC params would be a good best practice, but i think there still needs to be an overriding mechanism
Jan 20 11:23:24 <avalanche123>	I was just proposing to modify renderer to look them up in DIC first
Jan 20 11:23:32 <avalanche123>	not changing existing rendering
Jan 20 11:23:58 <Stof>	I think calling FOSUserBundle:User:show.html.twig should look for child bundles, not the opposite
Jan 20 11:24:11 <beberlei>	isnt that how it works?
Jan 20 11:24:18 <jmikola|w>	Stof: this seems like an issue of late-static binding :)
Jan 20 11:24:37 <Stof>	it is not what has been suggested just before
Jan 20 11:24:38 <beberlei>	how would a bundle developer know what name the child has?
Jan 20 11:25:02 <jmikola|w>	i think the logic behind a bundle having a parent is that the child can take the place of the parent's name, correct?
Jan 20 11:25:03 <fabpot>	ok, let me explain
Jan 20 11:25:09 <avalanche123>	I mean since the template names are already shortcuts resolved by convention, wouldn't ability to explicitly short-cut comething be helpful?
Jan 20 11:25:10 <fabpot>	You have bundle A
Jan 20 11:25:13 <fabpot>	B extends A
Jan 20 11:25:27 <lsmith>	just FYI .. there is 5 more minutes on this time box
Jan 20 11:25:29 <fabpot>	So, when you use A:foo.html.twig, Symfony2 will look for the template in B, then A
Jan 20 11:25:36 <beberlei>	yah
Jan 20 11:25:40 <Stof>	ok
Jan 20 11:25:41 <jmikola|w>	fabpot: any concern if there was a C that also extended A?
Jan 20 11:25:46 <beberlei>	what if you do B:foo.html.twig?
Jan 20 11:25:47 <jmikola|w>	or is that an unsupported edge case
Jan 20 11:25:52 <naderman>	jmikola|w: that behaviour is undefined
Jan 20 11:25:53 <fabpot>	If C extends A, you will have an exception
Jan 20 11:25:58 <naderman>	Seldaek suggested to throw an exception
Jan 20 11:25:59 <naderman>	ah
Jan 20 11:25:59 <Stof>	jmikola|w: is it unsupported
Jan 20 11:26:00 <beberlei>	jmikola|w: throws exception
Jan 20 11:26:09 <fabpot>	but C can extends B and B extend A
Jan 20 11:26:19 <jmikola|w>	right, that sounds reasonable then
Jan 20 11:26:27 <fabpot>	have a look at the unit tests
Jan 20 11:26:37 <jmikola|w>	beberlei: i'd think B would go directly to the extending bundle
Jan 20 11:26:46 <jmikola|w>	or possibly something that extended IT
Jan 20 11:26:50 <beberlei>	fabpot: is asking for "B:foo.twig.html" cascaded to the parents also? bi-directional inheritance?
Jan 20 11:26:53 *	bschussek (~yaaic@ has left #symfony-dev
Jan 20 11:26:55 <naderman>	and since it can be dynamic you can even build a C which extends B if it exists and A directly otherwise
Jan 20 11:26:56 <fabpot>	tests/Symfony/Tests/Component/HttpKernel/KernelTest.php
Jan 20 11:27:03 <fabpot>	beberlei: nope
Jan 20 11:27:04 <Stof>	beberlei: seems weird
Jan 20 11:27:09 <beberlei>	yes i know
Jan 20 11:27:11 <beberlei>	just asking
Jan 20 11:27:25 <beberlei>	*preparing zeh pop quiz* :)
Jan 20 11:28:00 *	nielsie has quit (Ping timeout: 264 seconds)
Jan 20 11:28:06 <Seldaek>	ok I guess it makes sense.. but I wonder if everyone is a bit confused here how it's gonna fare with end users.. Let's hope decent docs will help everyone.
Jan 20 11:28:26 *	rande ( has joined #symfony-dev
Jan 20 11:28:44 <fabpot>	Seldaek: I think it's pretty simple to explain in the doc, much easier than the current namespace prefixes
Jan 20 11:28:54 <lsmith>	ok .. next topic then ..
Jan 20 11:28:55 <lsmith>	Change option naming convention to camelcase :
Jan 20 11:28:56 <Seldaek>	fabpot: yeah fair enough :)
Jan 20 11:29:30 <jmikola|w>	looks like bernhard dropped out
Jan 20 11:29:33 <Seldaek>	so, changing all options everywhere except in command line stuff to camelCase.. +1/-1 ?
Jan 20 11:29:41 <henrikbjorn>	-1
Jan 20 11:29:48 *	srohweder has quit (Quit: Lost terminal)
Jan 20 11:29:50 <Seldaek>	I already mentionned the problem before with routing params leaking into php vars which were awkward
Jan 20 11:29:55 <avalanche123>	I don't mind as long as its consistent everywhere
Jan 20 11:30:11 <jmikola|w>	are routing params a concern? that's entirely up to the developer afaik
Jan 20 11:30:20 <Seldaek>	and bernhard mentionned that he'd like to have them so you can reuse option names to assign directly values on to an object's properties
Jan 20 11:30:23 <jmikola|w>	unlike core things like constraints or form options
Jan 20 11:30:30 <avalanche123>	well they sould be comel-cased as they are used in PHP too
Jan 20 11:30:34 <Seldaek>	jmikola|w: well, if we change we change it all..
Jan 20 11:30:35 <avalanche123>	*camel
Jan 20 11:30:37 <fabpot>	I really dislike camelCase, I really like my underscores in YAML and my - in XML, but consistency is probably the best way to go... unfortunately :(
Jan 20 11:30:43 <henrikbjorn>	Also command
Jan 20 11:30:43 <lsmith>	what would this all cover? how do we deal with DIC parameters that get send to services?
Jan 20 11:30:47 <henrikbjorn>	All or nothing
Jan 20 11:30:59 <avalanche123>	henrikbjorn, fabpot +1
Jan 20 11:31:02 <naderman>	camelCase in xml isn't even that uncommon
Jan 20 11:31:03 <lsmith>	are they camelcase in the DIC? which wouldnt fly well in XML
Jan 20 11:31:08 <naderman>	so I think that's alright
Jan 20 11:31:18 <henrikbjorn>	Lsmith they would be funny looking and camelcase sucks for parameters
Jan 20 11:31:40 <lsmith>	i just cant bare any more of this - to _ conversion code in extensions
Jan 20 11:31:43 <avalanche123>	so now instead of doctrine_odm.mongodb: we would have doctrineOdm.mongodb: ?
Jan 20 11:31:46 <lsmith>	it drives me nuts to read it
Jan 20 11:31:49 <Seldaek>	I don't see the problem with camel case personally, but I think we should also think about service names if we rename all parameters
Jan 20 11:31:52 <avalanche123>	in the yaml app config
Jan 20 11:32:08 <lsmith>	and its a source for bugs for different config formats ..
Jan 20 11:32:09 <jmikola|w>	avalanche123: camel case for acronyms gets weird, too... some people capitalize all of it, others just the first letter
Jan 20 11:32:10 <henrikbjorn>	Avalanche123 yeah
Jan 20 11:32:15 <lsmith>	so what ever gets rid of that .. i would be +1000
Jan 20 11:32:16 <henrikbjorn>	Which sucks
Jan 20 11:32:34 <lsmith>	jmikola|w: i think we have been sticking to ucfirst() for acronyms in many places
Jan 20 11:32:36 <Seldaek>	jmikola|w: I think the standard on that is first letter only, but again, we just have to specify it, then we can point people to it
Jan 20 11:32:55 <avalanche123>	jmikola|w, I think it was decided that a standard it not to uppercase all letter of an acronym, only the first one
Jan 20 11:33:05 <Seldaek>	I don't mind how people do it in their project, but in core we can enforce whatever decision we take
Jan 20 11:33:36 <lsmith>	how do we go about changing this?
Jan 20 11:33:42 <lsmith>	one bundle at a time?
Jan 20 11:33:59 <henrikbjorn>	Was i voted for?
Jan 20 11:34:03 <lsmith>	it will break many open pull requests
Jan 20 11:34:05 <henrikbjorn>	It*
Jan 20 11:34:13 *	unknownbliss (~unknownbl@unaffiliated/unknownbliss) has joined #symfony-dev
Jan 20 11:34:14 <naderman>	Seldaek: acronyms with only one uppercase letter is already being used though, no?
Jan 20 11:34:16 <lsmith>	henrikbjorn: nope ..
Jan 20 11:34:20 <fabpot>	lsmith: it will break EVERYTHING
Jan 20 11:34:23 <beberlei>	camel case in xml? ieeeks!
Jan 20 11:34:23 *	webPragmatist (~webby@unaffiliated/webpragmatist) has left #symfony-dev
Jan 20 11:34:24 <henrikbjorn>	It will break all apps
Jan 20 11:34:33 <lsmith>	yeah
Jan 20 11:34:44 <jmikola|w>	forgive me if this was answered, but wasn't bernhard mostly referring to validator/forms?
Jan 20 11:34:45 <avalanche123>	yeah, seems very messy, will look much more like java
Jan 20 11:34:54 <beberlei>	i thought it was about camel case in php
Jan 20 11:34:56 <jmikola|w>	or those configs really comparable to DIC stuff and routing?
Jan 20 11:34:56 *	webPragmatist (~webby@ has joined #symfony-dev
Jan 20 11:34:56 *	webPragmatist has quit (Changing host)
Jan 20 11:34:56 *	webPragmatist (~webby@unaffiliated/webpragmatist) has joined #symfony-dev
Jan 20 11:34:57 <beberlei>	not in yml and xml
Jan 20 11:35:06 <lsmith>	seeing beberlei's heart attack .. how do we deal with Doctrine?
Jan 20 11:35:13 <naderman>	beberlei: it's about avoiding to have to convert stuff now ;-)
Jan 20 11:35:15 <beberlei>	i dont comply!
Jan 20 11:35:16 <avalanche123>	jmikola|w for consistency, we would change all or nothing I think
Jan 20 11:35:53 <beberlei>	if its about yml and xml config also i say no
Jan 20 11:36:00 <jmikola|w>	even if we avoided camel case, we'd have to settle between _ and -, correct? i think _ is the most portable (for all the formats)
Jan 20 11:36:07 <beberlei>	if people cant think in contexts then its their problem
Jan 20 11:36:08 <henrikbjorn>	Beberlei same its nasty
Jan 20 11:36:09 <pgodel_work>	if camelCase is used for methods, variables but not for parameters, why does it have to be all the way in configuration ?
Jan 20 11:36:14 <fabpot>	ok, based on the feedback here, I think we need to think about this a bit more before changing anything
Jan 20 11:36:16 <Stof>	beberlei: the problem is that some parameters are defined in XML and used in PHP (for routing for example)
Jan 20 11:36:20 <bobthecow>	beberlei: +1
Jan 20 11:36:22 <Stof>	so they are in both worlds
Jan 20 11:36:33 <jmikola|w>	fabpot: +1
Jan 20 11:36:34 <avalanche123>	after thinking about it more, I am against camel case in yml and xmx
Jan 20 11:36:37 <Seldaek>	the problem is that property names are camelcase, so you can't just remove _'s and be done with it, you gotta uppercase what follows
Jan 20 11:36:49 <henrikbjorn>	Jmikola xml and html uses - which yaml can use too
Jan 20 11:36:51 <mvrhov>	so why don't we normailize everything?
Jan 20 11:36:59 <beberlei>	expensive
Jan 20 11:37:01 <mvrhov>	to camelcase before using it
Jan 20 11:37:01 <bobthecow>	zend has a great library for converting between underscored and camelcase.
Jan 20 11:37:03 <beberlei>	and wasted cpu time
Jan 20 11:37:05 <jmikola|w>	i'm leaning against camel case in general though
Jan 20 11:37:36 <fabpot>	bobthecow: lol
Jan 20 11:38:13 <Seldaek>	beberlei: the problem was that bernhard wants to remap options to object properties in the form framework, and you can't have properties with -, and you don't want properties with _
Jan 20 11:38:13 <naderman>	library o_O
Jan 20 11:38:16 <bobthecow>	could make a camelcase pass to normalize imported configs.
Jan 20 11:38:35 <Seldaek>	converting automatically will lead to countless WTFs
Jan 20 11:38:38 <Seldaek>	let's not go there
Jan 20 11:38:48 <bobthecow>	not if there's a well defined conversion algorithm.
Jan 20 11:38:51 <Seldaek>	even if it's fast I don't care
Jan 20 11:39:02 <Seldaek>	you type a value in your config, you expect the same in your php code
Jan 20 11:39:27 <avalanche123>	bobthecow, in the code you would have to call $container->getParameter('camelCasedName') still
Jan 20 11:39:39 <bobthecow>	ooh. true.
Jan 20 11:39:50 <fabpot>	I think everything has been said
Jan 20 11:40:02 <fabpot>	and it looks like we won't change the current conventions anytime soon
Jan 20 11:40:18 <Seldaek>	yeah, let's see what bernhard thinks after reading the log :)
Jan 20 11:40:23 <avalanche123>	:)
Jan 20 11:40:39 <lsmith>	ok
Jan 20 11:40:41 *	nielsie ( has joined #symfony-dev
Jan 20 11:40:48 <lsmith>	next topic
Jan 20 11:41:05 <lsmith>	this one only has 3 votes .. but thats because i screwed up and a few votes got deleted
Jan 20 11:41:05 <lsmith>	load extension configs once:,
Jan 20 11:41:14 <lsmith>	johanness created a branch
Jan 20 11:41:17 <jmikola|w>
Jan 20 11:41:24 <lsmith>	right
Jan 20 11:41:29 <lsmith>	this is only the first step of course
Jan 20 11:41:29 <jmikola|w>	fabpot: did you get my github response about this?
Jan 20 11:41:38 <lsmith>	we will want to add smarter merging algo's
Jan 20 11:41:40 <fabpot>	jmikola|w: hmmm, not sure
Jan 20 11:41:45 *	iAsteris_ has quit (Quit: Computer has gone to sleep.)
Jan 20 11:41:50 <lsmith>	rather than just replicating the existing approach of calling the load methods for each config
Jan 20 11:41:59 <jmikola|w>	so lsmith alerted me to johannes work after our convo tuesday (when you asked about me doing this)
Jan 20 11:42:00 *	wSuFF_ has quit (Quit: Computer has gone to sleep.)
Jan 20 11:42:17 <fabpot>	lsmith: Don't even think about merging algo. Merging is the responsibility of each extension.
Jan 20 11:42:17 <jmikola|w>	johanness was in support of not having a separate merge method, as not everyone will need it
Jan 20 11:42:27 <lsmith>	fabpot: thats what i mean
Jan 20 11:42:32 <jmikola|w>	so he passes all the configs to the load() method
Jan 20 11:42:44 <lsmith>	the above patch updates all extensions to loop over all configs and call the load method
Jan 20 11:42:53 <lsmith>	which is exactly the behavior we have now
Jan 20 11:43:00 <fabpot>	as johanness  and jmikola|w  is working on the topic, and as it's not finished yet, do we want to re-talk about that now?
Jan 20 11:43:05 <jmikola|w>	his commit isn't thoroughly tested, but it's fairly backwards compatible and we could start transitioning to make the merging as we have time
Jan 20 11:43:06 <lsmith>	and then in step two we update the extensions to do something intelligent
Jan 20 11:43:16 <fabpot>	lsmith: yes, that was not what we decided last time IIRC
Jan 20 11:43:19 <avalanche123>	I agree with fabpot, let's table it for later discussion
Jan 20 11:43:23 <lsmith>	fabpot: the main question is if we agree on the API
Jan 20 11:43:34 <lsmith>	aka the load method gets an array with all the configs
Jan 20 11:43:39 <jmikola|w>	well, if johanness's patch is BC and we can get it into core, people can start working off that to port extensions over
Jan 20 11:44:12 <Stof>	fabpot: lsmith is talking about each core extension, not about creating a generic load method
Jan 20 11:44:12 <jmikola|w>	it would be a bit more difficult coordinating a giant pull request with many hands involved to port all the extensions at once
Jan 20 11:44:13 <lsmith>	basically imho the patch is ready to be pulled
Jan 20 11:44:16 <Seldaek>	lsmith: why not call a merge method with all config arrays, so by default it's implemented as foreach($configs as $config) $this->load($config), and if you like smarter you override
Jan 20 11:44:35 <lsmith>	Seldaek: if at all .. the default merge method would return the last
Jan 20 11:44:38 <lsmith>	but its not possible
Jan 20 11:44:39 <fabpot>	we talked about what to do last time, and we need to stick with it, except if something happened in the meantime
Jan 20 11:44:45 <lsmith>	since you can have multiple load methods
Jan 20 11:44:51 <lsmith>	you need multiple merge methods
Jan 20 11:44:53 <Seldaek>	lsmith: ah right
Jan 20 11:44:57 <Seldaek>	nvm then
Jan 20 11:45:06 <lsmith>	which means a default is impossible without a method exists check
Jan 20 11:45:12 <lsmith>	which is why i think a single load method is the way to go
Jan 20 11:45:15 <lsmith>	no merge method
Jan 20 11:45:28 <naderman>	I'd just like to suggest that there are some convenience methods for merging configurations you can use, so stuff like those remap methods we've seen aren't copy&pasted into all extensions that need them
Jan 20 11:45:30 <Stof>	yeah, johannes patch seems good.
Jan 20 11:45:35 <lsmith>	last time IIRC we wanted a merge method ..
Jan 20 11:45:37 <jmikola|w>	lsmith: i suppose one question on johanness' patch... he has a protected method and one public, which makes unit testing the loading and merging independently not trivial
Jan 20 11:45:49 <Seldaek>	makes sense, and the fact that you get an array of configs is probably better so that every extension developer is aware of the problem that they get multiple configs (and not just one pass)
Jan 20 11:46:05 <lsmith>	jmikola|w: just unit test the protected one via the public one
Jan 20 11:46:09 <lsmith>	or use proxies ..
Jan 20 11:46:21 <lsmith>	or for most cases i dont think the load will do much of anything fancy
Jan 20 11:46:25 <Stof>	then the core extensions will need to be refactored to be sure the merging is the best used
Jan 20 11:46:27 <jmikola|w>	is that what we'll do for core unit tests, though?
Jan 20 11:46:31 <fabpot>	Seldaek: true
Jan 20 11:46:33 <lsmith>	so i wouldnt even bother with unit (maybe functional tests)
Jan 20 11:46:33 *	AlHornair has quit (Quit: Ex-Chat)
Jan 20 11:46:39 <jmikola|w>	lsmith: agreed, the merging logic is essentially, at some point in the config block, you just override keys
Jan 20 11:47:21 <beberlei>	lsmith: i disagree
Jan 20 11:47:21 <lsmith>	ok .. sounds like the branch is good and the next step is updating each extension
Jan 20 11:47:29 <jmikola|w>	so, if johanness' branch can get into core, i will take on porting over FrameworkExtension
Jan 20 11:47:34 <beberlei>	the merging is pretty complicated in case of security or doctrine extension
Jan 20 11:47:39 <beberlei>	i want to test it withought hickups
Jan 20 11:47:39 <jmikola|w>	I assume johanness would do Security - but we can coordinate on the mailing list
Jan 20 11:47:42 <lsmith>	beberlei: unit test junkies need to know how to do proxies
Jan 20 11:47:58 <avalanche123>	beberlei +1 this method should be explicit and public
Jan 20 11:48:09 <beberlei>	has nothing to do with junkie, i want to stuff two arrays in get one array out
Jan 20 11:48:17 <beberlei>	what proxy btw?
Jan 20 11:48:26 <beberlei>	to detect hundrets of calls to the container?
Jan 20 11:48:36 <lsmith>	beberlei: to test protected methods in unit tests you need to create a proxy with adjusted visibility
Jan 20 11:48:42 <lsmith>	anyway .. off topic
Jan 20 11:48:50 <beberlei>	ah that ugly thing :)
Jan 20 11:48:52 <avalanche123>	lsmith if you are testing protected methods, you're doing it wrong:)
Jan 20 11:48:52 <jmikola|w>	beberlei: i think a sane unit test would just pass in a virgin ContainerBuilder and then assert it's state after - no crazy mocking
Jan 20 11:48:55 <Stof>	beberlei: johannes patch does exactly what is actually done in the extension by loading each config separatlty
Jan 20 11:48:56 <naderman>	lsmith: hence the suggestion not to have it protected
Jan 20 11:49:00 *	henrikbjorn has quit (Ping timeout: 264 seconds)
Jan 20 11:49:06 *	daniel123 ( has joined #symfony-dev
Jan 20 11:49:10 <lsmith>	but its not called from the outside
Jan 20 11:49:20 <lsmith>	the load method is .. and then it does whatever it pleases
Jan 20 11:49:26 *	henrikbjorn ( has joined #symfony-dev
Jan 20 11:49:34 <Stof>	and it is not even mandatory if it uses a true merging
Jan 20 11:49:37 <lsmith>	it can just do $config = array_pop($configs)
Jan 20 11:49:42 <lsmith>	and not bother with a separate method at all
Jan 20 11:49:50 <avalanche123>	that I agree with
Jan 20 11:50:00 <lsmith>	so why make two methods public?
Jan 20 11:50:05 <jmikola|w>	lsmith: then perhaps to set a good example for core extensions would be to do the merging in a separate method, even if that's not a required interface?
Jan 20 11:50:05 *	Garfield-fr has quit (Quit:  ⏏)
Jan 20 11:50:08 <lsmith>	there is only a need for one
Jan 20 11:50:09 <beberlei>	jmikola|w ok you are right
Jan 20 11:50:10 <avalanche123>	beberlei, I think if merging gets too complicated, you could extract a Merger... dunno
Jan 20 11:50:19 <beberlei>	virgin container + asserting there is good
Jan 20 11:50:32 <lsmith>	simple extension dont need one, complex one will have one
Jan 20 11:50:33 <lsmith>	yes
Jan 20 11:50:45 <lsmith>	ok .. we only have 10 minutes ..
Jan 20 11:50:51 <lsmith>	lets go to the next topic, ok?
Jan 20 11:50:54 <avalanche123>	sure
Jan 20 11:50:55 <lsmith>	Request changes:
Jan 20 11:51:02 <lsmith>	avalanche123: take it away
Jan 20 11:51:06 <avalanche123>	hi
Jan 20 11:51:13 <avalanche123>	so basically here is my point of view
Jan 20 11:51:23 <avalanche123>	request -> parameters -> controller -> parameters -> view
Jan 20 11:51:31 <avalanche123>	for requests with request body
Jan 20 11:51:45 <avalanche123>	the body needs to be parsed into $request arguments
Jan 20 11:52:08 <avalanche123>	that way you could have the same controller handle json and form requests
Jan 20 11:52:13 <avalanche123>	*ideally*
Jan 20 11:52:33 <avalanche123>	so then we would have request body parsers (whatever you call them)
Jan 20 11:52:39 <henrikbjorn>	I dont get that
Jan 20 11:52:48 <avalanche123>	form post looks like
Jan 20 11:52:49 <henrikbjorn>	Why cant it do that now?
Jan 20 11:52:59 <avalanche123>	key=val&key2=val
Jan 20 11:53:07 <jmikola|w>	henrikbjorn: currently it sets request property based on $_POST
Jan 20 11:53:14 <avalanche123>	henrikbjorn right now request gets whatever is in $_POST
Jan 20 11:53:27 <avalanche123>	but for json and xml requests, that array is empty
Jan 20 11:53:31 <kriswallsmith>	how would you read the request body?
Jan 20 11:53:36 <jmikola|w>	so avalanche123 is proposing changing the default request value based on the content-type of the http request
Jan 20 11:53:38 <avalanche123>	as you post a jxon object
Jan 20 11:54:02 *	kertz_ (~kertz@ has joined #symfony-dev
Jan 20 11:54:11 <avalanche123>	form post has content type of application/x-*www-form*-*urlencoded*
Jan 20 11:54:12 <naderman>	kriswallsmith: http_get_request_body() ?
Jan 20 11:54:22 <Seldaek>	btw just so everyone knows (I already told avalanche123), I started working on a Serializer component (that the new fabpot-compliant View would be based on), this could also be used to decode http POST data
Jan 20 11:54:23 <avalanche123>	and json post would be application/json
Jan 20 11:54:44 <avalanche123>	so you could chose how to process request body based on content-type
Jan 20 11:54:44 <igorw>	naderman: that's pecl
Jan 20 11:54:48 <naderman>	oh
Jan 20 11:55:06 <avalanche123>	but to do that we would have to change how request is initialized
Jan 20 11:55:08 <Seldaek>	kriswallsmith: you can file_get_contents('php://input') as well to read the body
Jan 20 11:55:12 <henrikbjorn>	Is this in correspondance with the http protocol?
Jan 20 11:55:14 <fabpot>	avalanche123: we already had a pull request for that, and it was rejected as too magic was involved
Jan 20 11:55:21 *	tecbot has quit ()
Jan 20 11:55:22 <fabpot>	so it should be done outside of the Request class
Jan 20 11:55:31 <avalanche123>	fabpot, I agree
Jan 20 11:55:40 <avalanche123>	so my point was to make Kernel populate empty request
Jan 20 11:55:47 <fabpot>	but, I'm in favor of having something to deal with that
Jan 20 11:55:50 <avalanche123>	instead of request populating itself
Jan 20 11:56:02 <jmikola|w>	avalanche123: i think request can still default to $_POST though, right?
Jan 20 11:56:05 <avalanche123>	so the request class would be very similar to response class
Jan 20 11:56:16 <jmikola|w>	or would that default value be removed entirely
Jan 20 11:56:28 <naderman>	fabpot: well I think it makes sense for the request class to provide the raw data, and Seldaek's (un)serializer to handle the conversion to objects later
Jan 20 11:56:29 <avalanche123>	it would be registered on application/x-*www-form*-*urlencoded*  request type
Jan 20 11:56:33 *	kertz has quit (Ping timeout: 240 seconds)
Jan 20 11:56:33 *	kertz_ is now known as kertz
Jan 20 11:56:35 <fabpot>	avalanche123: that's a small change and seems reasonnable. You need to check that it does not break anything.
Jan 20 11:56:35 <avalanche123>	and the multipart one
Jan 20 11:56:38 <mvrhov>	Seldaek, weren't there some problems with php://input ?
Jan 20 11:56:46 <fabpot>	naderman: yes
Jan 20 11:56:57 <avalanche123>	fabpot, yeah, I will start on it and ping you with questions if anything
Jan 20 11:57:09 <Seldaek>	mvrhov: it can just be read once, but that's it
Jan 20 11:57:20 <avalanche123>	and we don't need more than once
Jan 20 11:57:23 <lsmith>	ok .. last topic spills over from this one .. Parameter converters:
Jan 20 11:57:23 <Seldaek>	mvrhov: well, only once on SOME SAPIs, but it's available everywhere
Jan 20 11:57:30 <fabpot>	Seldaek: but the request already take care of that
Jan 20 11:57:31 <avalanche123>	me again:)
Jan 20 11:57:42 <avalanche123>	I think it was clear what it was about to everyone on the ml
Jan 20 11:57:43 <Seldaek>	fabpot: yeah sure, I was just answering kriswallsmith's question :
Jan 20 11:58:09 <avalanche123>	basically making explicit registration of parameter converter per parameter would allow for bi-directional conversion
Jan 20 11:58:34 <avalanche123>	fabpot to your point about routing component's responsibility, I think we could just create a custom loader in framework bundle
Jan 20 11:58:42 <avalanche123>	that would take parameters: into account
Jan 20 11:58:44 <beberlei>	is that a necessary use-case?
Jan 20 11:59:00 <avalanche123>	beberlei I dunno, seems useful
Jan 20 11:59:02 <beberlei>	i mean i really know how i convert my object back to an identifier when i am using Router::generate
Jan 20 11:59:07 *	ornicar (~ornicar@ has joined #symfony-dev
Jan 20 11:59:08 <fabpot>	avalanche123: routing does one thing and it won't do anything else. I won't re-create the ObjectRoute nightmare from symfony1
Jan 20 11:59:23 <avalanche123>	I am not familiar with that:)
Jan 20 11:59:26 <fabpot>	beberlei: +1
Jan 20 11:59:32 <fabpot>	avalanche123: trust me
Jan 20 11:59:34 <jmikola|w>	avalanche123: that's what i was talking to you about the other day
Jan 20 11:59:42 <avalanche123>	I get your point:)
Jan 20 11:59:49 <henrikbjorn>	I think maybe we should slim them down and not send the request with the apply method?
Jan 20 12:00:25 <kriswallsmith>	i think you can only read from php://input once
Jan 20 12:00:28 <Seldaek>	avalanche123: I think that thing could be built on top of controllers with annotations (at least for the deserializing)
Jan 20 12:00:37 <naderman>	kriswallsmith: yes, see fabpot's answer above
Jan 20 12:00:55 <avalanche123>	Seldaek, yeah, I will have to see about that
Jan 20 12:01:01 <fabpot>	Seldaek: that's what I started in FrameworkExtraBundle
Jan 20 12:01:15 <avalanche123>	fabpot, should we get rid of them period?
Jan 20 12:01:15 <Seldaek>	yup, I think it's not something that needs to be in core
Jan 20 12:01:22 <Seldaek>	and we should forget about it until final is out :)
Jan 20 12:01:33 <fabpot>	Seldaek: hehe, +1
Jan 20 12:01:49 <henrikbjorn>	Maybe we should moe them back out of core?
Jan 20 12:01:52 <fabpot>	avalanche123: I think we need to work on more important features for now
Jan 20 12:01:52 <Seldaek>	there's enough other things to tend to I guess
Jan 20 12:02:06 <avalanche123>	fabpot agreed
Jan 20 12:02:14 <Seldaek>	fabpot: I'll submit that serializer thingy this weekend hopefully.. at least a basic version for review
Jan 20 12:02:16 <fabpot>	henrikbjorn: yeah, that's what I was thinking
Jan 20 12:02:26 <henrikbjorn>	Lets do that
Jan 20 12:02:31 <avalanche123>	henrikbjorn +1
Jan 20 12:02:38 <lsmith>	ok ..
Jan 20 12:02:43 <lsmith>	guess time is up and stuff
Jan 20 12:02:53 <beberlei>	yay to the alc now
Jan 20 12:02:55 <beberlei>	err
Jan 20 12:03:00 <lsmith>	thx for everybody talking so much ... summary will be a ton of work :-/
Jan 20 12:03:04 <henrikbjorn>	Fabpot should it still rely on annotations in frameworkextra?
Jan 20 12:03:12 <avalanche123>	thanks for great discussion
Jan 20 12:03:13 <beberlei>	lsmith: we know how to make you happy
Jan 20 12:03:31 <fabpot>	henrikbjorn: it already does not rely on annotations, except if you want to pass parameters
Jan 20 12:03:35 <lsmith>	i need a padawan for this stuff
Jan 20 12:03:46 <weaverryan>	lsmith: Thanks for doing the summary though - I missed almost all of this meeting
Jan 20 12:03:48 <beberlei>	i thought that was Seldaek ? :)
Jan 20 12:03:50 <Seldaek>	lsmith: and for extra fun jmikola|w didn't copy the log this time so you gotta do it yourself :P
Jan 20 12:03:59 <jmikola|w>	Seldaek: i'm doing it now :)