Log of #symfony-dev meeting 20101202 (all times GMT-5)

transcript.txt

Dec 02 11:00:45 <lsmith>	ok let goo
Dec 02 11:00:59 <lsmith>	first topic is Custom loader resources notation: http://bit.ly/gexEh0
Dec 02 11:01:21 <lsmith>	i should note .. i kinda had hard time picking topics for this meeting
Dec 02 11:01:27 <mvrhov>	lsmith, the passwords and the scheme... would you care to explain where exacty is the prblm
Dec 02 11:01:30 <lsmith>	because nobody really made any explicit proposals
Dec 02 11:01:39 <ornicar>	lsmith WTF is this $facebookId https://github.com/liip/DoctrineUserBundle/commit/6cd3fb820882d533384497e817beac07a4c2c6c9#L1R52
Dec 02 11:01:40 <lsmith>	mvrhov: after the meeting
Dec 02 11:01:45 <ornicar>	I never saw it before
Dec 02 11:01:58 <lsmith>	ornicar: oops
Dec 02 11:02:01 <lsmith>	anyway meeting time
Dec 02 11:02:07 <ornicar>	ok :D
Dec 02 11:02:27 <yclian>	lsmith, probably maintain a big pool, like a wish-to-be-discussed-list, or to have a roadmap doc that we can easily generate topics for meeting?
Dec 02 11:02:35 <fabpot>	If I understand correctly, most people want the first notation I proposed:
Dec 02 11:02:36 <fabpot>	imports:
Dec 02 11:02:36 <fabpot>	   - { resource: file:BlogBundle/Controller/AnnotController.php }
Dec 02 11:02:37 <fabpot>	   - { resource: annotations:BlogBundle/Controller/AnnotController.php }
Dec 02 11:02:48 <fabpot>	the prefix is always mandatory
Dec 02 11:03:04 <fabpot>	any comment on this choice?
Dec 02 11:03:09 <jmikola|w>	and that would apply the same for XML? <import resource="file:..." />
Dec 02 11:03:18 <henrikbjorn>	Default to file
Dec 02 11:03:21 <fabpot>	jmikola: sure, XML, PHP, and YAML
Dec 02 11:03:23 <lsmith>	yclian: the "system" is easy .. just propose topics .. anything that doesnt get discussed i usually just put on for the next meeting
Dec 02 11:03:23 <Seldaek>	why not drop the resource: then in that case?
Dec 02 11:03:27 <rande>	I don't see the point of the resource key
Dec 02 11:03:31 <Seldaek>	I liked that option
Dec 02 11:03:47 <fabpot>	because the prefix can be anything
Dec 02 11:03:51 <Seldaek>	just do: import:\n - file:Foo\n - file:Bar
Dec 02 11:03:59 <Seldaek>	then it's an array of strings
Dec 02 11:04:09 <henrikbjorn>	But if file is mandatory then drop the resource and just have it be an array
Dec 02 11:04:40 <henrikbjorn>	Exactly as seldaek just wrote :)
Dec 02 11:05:11 <jmikola|w>	the resource key is needed for XML/YML... in PHP that's just be the first argument to import()
Dec 02 11:05:17 <rande>	unless 'file' is a registered wrapper that we can change
Dec 02 11:05:17 <jmikola|w>	if I understand correctly
Dec 02 11:05:26 <rande>	ie : loading routes information from a database
Dec 02 11:05:30 <jmikola|w>	afaik, file would just auto-detect a loader based on the extension, yes?
Dec 02 11:05:54 <fabpot>	import:
Dec 02 11:05:54 <fabpot>	    file: foo.php
Dec 02 11:05:54 <fabpot>	    file: foo.xml
Dec 02 11:05:57 <fabpot>	does not work
Dec 02 11:06:01 <henrikbjorn>	Jmikola in yaml it dosent make sense to prefix it
Dec 02 11:06:02 <fabpot>	you will only have the last one
Dec 02 11:06:07 <henrikbjorn>	With resource
Dec 02 11:06:35 <jmikola|w>	fabpot: I believe they meant - { file: foo.php }
Dec 02 11:06:36 *	bschussek ([email protected]) has joined #symfony-dev
Dec 02 11:06:45 <Seldaek>	fabpot: that's not what I'm saying
Dec 02 11:06:48 <Seldaek>	that is what I mean https://gist.github.com/725571
Dec 02 11:06:50 <jmikola|w>	still an array, but using the loader protocol instead of resource
Dec 02 11:06:57 <henrikbjorn>	Jmikola no
Dec 02 11:07:02 <fabpot>	like this
Dec 02 11:07:03 <fabpot>	import:
Dec 02 11:07:03 <fabpot>	    - { file: foo.php }
Dec 02 11:07:03 <fabpot>	    - { file: foo.xml }
Dec 02 11:07:06 <Seldaek>	no
Dec 02 11:07:12 <henrikbjorn>	No
Dec 02 11:07:13 <yclian>	<import resource=".."/> makes sense, but imports: [{ resource: ... }, ..] can be in better form.
Dec 02 11:07:13 <avalanche123>	I like it fabpot
Dec 02 11:07:21 <jmikola|w>	ah, Seldaek just an array of strings
Dec 02 11:07:24 <Seldaek>	if you do that, import becomes array(array('file'=>'foo.php'))
Dec 02 11:07:26 <henrikbjorn>	Yes
Dec 02 11:07:32 <Seldaek>	my solution just gives array('file:foo.php')
Dec 02 11:07:45 <fabpot>	this then
Dec 02 11:07:45 <fabpot>	import:
Dec 02 11:07:46 <fabpot>	    - 'file: foo.php'
Dec 02 11:07:46 <fabpot>	    - 'file: foo.xml'
Dec 02 11:07:53 <Seldaek>	yes, that's equal to https://gist.github.com/725571
Dec 02 11:07:59 <henrikbjorn>	Yes
Dec 02 11:07:59 <Seldaek>	you don't need the quotes and no space either imo
Dec 02 11:08:00 <jmikola|w>	Seldaek: in XML, that would then become <import>file:...</import>
Dec 02 11:08:05 <jmikola|w>	since we loose an attribute name
Dec 02 11:08:24 <Seldaek>	jmikola|w: yes, <imports><import>foo</import></imports>
Dec 02 11:08:53 <fabpot>	what if we want to be able to add other options later on?
Dec 02 11:09:03 <bschussek>	exactly. we lose an extension point here
Dec 02 11:09:06 <Seldaek>	well then you need the second level..
Dec 02 11:09:08 <fabpot>	wait a minute, we already have some
Dec 02 11:09:20 <avalanche123>	imports:
Dec 02 11:09:20 <avalanche123>	    xml: [foo.xml, bar.xml]
Dec 02 11:09:20 <avalanche123>	    restful:
Dec 02 11:09:20 <avalanche123>	     - Bundle\Controller\RestfulController
Dec 02 11:09:20 <avalanche123>	     - AnotherBundle\Controller\RestfulController
Dec 02 11:09:25 <avalanche123>	?
Dec 02 11:09:35 <henrikbjorn>	Bulat +1
Dec 02 11:09:45 <henrikbjorn>	Insted of xml just file
Dec 02 11:09:48 <Seldaek>	you still lose the extensibility there
Dec 02 11:10:05 <kriswallsmith>	You can tell import to ignore the error if the resource doesn't exist
Dec 02 11:10:17 <fabpot>	kriswallsmith: yes
Dec 02 11:10:18 <jmikola|w>	avalanche123: how does that map to XML or PHP configs :)
Dec 02 11:10:24 <henrikbjorn>	Then support both?
Dec 02 11:10:44 <kriswallsmith>	Not both :(
Dec 02 11:11:10 <henrikbjorn>	Why
Dec 02 11:11:13 <bschussek>	I think avalanche123's solution is worth a look
Dec 02 11:11:16 <fabpot>	  <imports>
Dec 02 11:11:16 <fabpot>	      <import resource="security.xml" ignore-errors="true" />
Dec 02 11:11:17 <fabpot>	      <import resource="something.xml" />
Dec 02 11:11:17 <fabpot>	  </imports>
Dec 02 11:11:22 <jmikola|w>	While we're throwing out code examples, this was my late suggestion on the mailing list: http://groups.google.com/group/symfony-devs/msg/fcb01daeb31b9f4d
Dec 02 11:11:31 <bschussek>	in YAML, we can expect a string by default, and an array if more options have to be given
Dec 02 11:11:39 <henrikbjorn>	Fabpot in xml the on-ignore could still be a attribute
Dec 02 11:11:41 <avalanche123>	bschussek +1
Dec 02 11:11:49 <bschussek>	- something.xml
Dec 02 11:11:51 <bschussek>	- { resource: security.xml, ignore-errors: true }
Dec 02 11:12:15 <henrikbjorn>	And the value would be the resource
Dec 02 11:12:19 <lsmith>	ok .. 3 more minutes on this topic
Dec 02 11:12:21 <fabpot>	bschussek: that's not consistent. We know from symfony1 that this is not a good idea to have two notations for the same thing
Dec 02 11:12:22 <kriswallsmith>	We already have a similar syntax for referencing templates
Dec 02 11:12:30 <kriswallsmith>	Let's use that
Dec 02 11:12:30 <jmikola|w>	why would ignore-errors be necessary?  isn't it a problem if the resource doesn't exist?
Dec 02 11:12:38 <kriswallsmith>	foo.annot
Dec 02 11:12:46 <fabpot>	jmikola|w: not always
Dec 02 11:12:52 <kriswallsmith>	Where foo is a directory
Dec 02 11:13:08 <Seldaek>	kriswallsmith: that doesn't work to import config files
Dec 02 11:13:22 <kriswallsmith>	jmikola|w: I think that's a nice feature, actually
Dec 02 11:13:24 <Seldaek>	kriswallsmith: also using the extension doesn't work because php has multiple importers iirc
Dec 02 11:13:42 <jmikola|w>	Seldaek: annotation and file at least
Dec 02 11:13:46 <kriswallsmith>	Seldaek: explain?
Dec 02 11:13:46 <bschussek>	fabpot: then my vote goes for using arrays always, with the attribute "type" for overriding the default value "file"
Dec 02 11:13:54 <jmikola|w>	file is really just shorthand for detecting yml/xml/php loader, correct?
Dec 02 11:14:05 <jmikola|w>	bschussek: i proposed this:
Dec 02 11:14:05 <jmikola|w>	YML: { resource: HelloBundle/Controller/HelloController.php, type:
Dec 02 11:14:05 <jmikola|w>	annotation }
Dec 02 11:14:05 <jmikola|w>	XML: <import resource="HelloBundle/Controller/HelloController.php"
Dec 02 11:14:05 <jmikola|w>	type="annotation" />
Dec 02 11:14:05 <jmikola|w>	PHP: $routeCollection->import('HelloBundle/Resources/config/routing.php',
Dec 02 11:14:05 <jmikola|w>	'annotation'); 
Dec 02 11:14:06 <yclian>	i think the ignore-errors example is nice too, although i wanted to raise that, something similar.. spring's <import resource=""/> has never changed since day 1. but yea, extensibility is stil lbetter.
Dec 02 11:14:15 <fabpot>	bschussek: type would probabmy be loader then, no?
Dec 02 11:14:25 <jmikola|w>	with type being optional for cases where it's ambiguous
Dec 02 11:14:29 <bschussek>	fabpot: yes
Dec 02 11:14:34 <avalanche123>	fabpot, I agree
Dec 02 11:14:36 <jmikola|w>	i.e. php extension, but not for yml/xml extensions
Dec 02 11:14:48 <henrikbjorn>	Why does the xml thing have to be all attributes
Dec 02 11:14:52 <avalanche123>	jmikola +1
Dec 02 11:15:01 <avalanche123>	I think its the most structured approach so far
Dec 02 11:15:02 <henrikbjorn>	The tag can have a value
Dec 02 11:15:04 <jmikola|w>	henrikbjorn: because we have two attributes at least, the file/path and the loader/type
Dec 02 11:15:17 <kriswallsmith>	jmikola|w: +1
Dec 02 11:15:22 <jmikola|w>	and using attributes for XML maps easily to YML/PHP syntax
Dec 02 11:15:23 <henrikbjorn>	The file/path could be the tag value
Dec 02 11:15:29 <avalanche123>	so fabpot jsut has to wait for a pull request from jmikola now:)
Dec 02 11:15:34 <jmikola|w>	boooo
Dec 02 11:15:34 <bschussek>	jmikola|w: +1
Dec 02 11:15:34 <lsmith>	ok ..
Dec 02 11:15:41 <lsmith>	then lets move on to the next topic
Dec 02 11:15:42 *	Dominique__ ([email protected]) has joined #symfony-dev
Dec 02 11:15:49 <jmikola|w>	fabpot: i'll work on it :)
Dec 02 11:15:55 <lsmith>	View layer: http://bit.ly/fjDmLK
Dec 02 11:16:04 <fabpot>	to be sure I understand what we decide:
Dec 02 11:16:08 <fabpot>	import:
Dec 02 11:16:08 <fabpot>	    - { resource: foo.php, loader: file }
Dec 02 11:16:08 <fabpot>	    - { resource: foo.xml, loader: file }
Dec 02 11:16:08 <fabpot>	<imports>
Dec 02 11:16:09 <fabpot>	    <import resource="security.xml" loader="file" ignore-errors="true" />
Dec 02 11:16:09 <fabpot>	    <import resource="something.xml" loader="file" />
Dec 02 11:16:09 <fabpot>	</imports>
Dec 02 11:16:12 <yclian>	+1
Dec 02 11:16:12 <Seldaek>	yes
Dec 02 11:16:22 <fabpot>	ok, good for me then
Dec 02 11:16:27 <jmikola|w>	fabpot: yup
Dec 02 11:16:39 <henrikbjorn>	-1
Dec 02 11:16:39 <lsmith>	ok for the view layer its not decision time ..
Dec 02 11:16:45 <henrikbjorn>	Over verbose
Dec 02 11:16:52 <lsmith>	but more an opportunity to answer questions ..
Dec 02 11:17:14 <Seldaek>	regarding the view layer, as you may have seen I updated the pull request yesterday, I have identified a couple issues and omissions since then that I'll fix, but if someone has comments or something to say..
Dec 02 11:17:19 <bschussek>	fabpot: I'd propose making loader "file" implicitely, if it is not given
Dec 02 11:17:27 <kriswallsmith>	ignore-errors is ambiguous, maybe ignore-not-found (fabpot)
Dec 02 11:17:45 <lsmith>	the key changes are that the redirect stuff is now "no magic"
Dec 02 11:18:02 <lsmith>	and there is now a way to inject "global" parameters into templates
Dec 02 11:18:32 <lsmith>	are there any questions on the view layer? any of its capabilities .. criticism?
Dec 02 11:18:48 <fabpot>	I don't want to talk about that as I have still many things that I want to change/talk about. I will write everything down to make things clearer
Dec 02 11:18:52 <henrikbjorn>	Why is it needed still dont get the usecases
Dec 02 11:18:57 <lsmith>	i should note we will probably also implement a version that extends the current view with the "magic" redirect stuff
Dec 02 11:19:16 <jmikola|w>	lsmith: as a separate bundle i hope? :)
Dec 02 11:19:16 <kriswallsmith>	henrikbjorn: +1
Dec 02 11:19:39 <lsmith>	henrikbjorn: the idea of the view layer is to separate view logic from the controller and templates
Dec 02 11:19:47 <fabpot>	henrikbjorn: the use case I see for now is for web services
Dec 02 11:19:51 <lsmith>	this way its much easier to write format independent controllers
Dec 02 11:19:59 <fabpot>	henrikbjorn: the current implementation is nice for read-only web services
Dec 02 11:20:12 <henrikbjorn>	It looks like the view layer is an extension of the returned request object
Dec 02 11:20:20 <jmikola|w>	so one thing i brought up in the git discussion, is it's helpful to know if you're redirecting to an off-site or internal url (easy to tell if we're making it from a route and params)
Dec 02 11:20:42 <Seldaek>	henrikbjorn: nah, the view just returns an response, but you don't have to go through the view layer to generate a response
Dec 02 11:20:59 <jmikola|w>	henrikbjorn: the view layer more or less can have logic to generate a response tailored to the request and other arguments
Dec 02 11:21:09 <rande>	the view layer is great if you want to output json, amf, xml or html with the same action
Dec 02 11:21:09 <jmikola|w>	so Seldaek and lsmith want it to respect the request format
Dec 02 11:21:11 <henrikbjorn>	What does the view deliver that dosent belong in a controller?
Dec 02 11:21:19 <kriswallsmith>	fabpot: will a controller be unaware of request format?
Dec 02 11:21:20 <henrikbjorn>	Jmikola isnt that the controllers job?
Dec 02 11:21:22 <lsmith>	rande: correct
Dec 02 11:21:27 <kriswallsmith>	i.e. a posted XML body
Dec 02 11:21:31 <Seldaek>	henrikbjorn: format-specific logic
Dec 02 11:21:39 <jmikola|w>	henrikbjorn: you can make a single view service that all controllers use to handle the formatting
Dec 02 11:21:42 <kriswallsmith>	vs form post url encoded
Dec 02 11:21:47 <jmikola|w>	instead of adding json/xml logic to each controller
Dec 02 11:21:49 <henrikbjorn>	But then we have the templs
Dec 02 11:22:02 <henrikbjorn>	Templates with format in their namr
Dec 02 11:22:06 <Seldaek>	henrikbjorn: templates are for html, for the rest they suck
Dec 02 11:22:07 <rande>	henrikbjorn: you cannot deal with amf in a template
Dec 02 11:22:11 <lsmith>	henrikbjorn: do you want to use twig to generate a pdf?
Dec 02 11:22:28 <henrikbjorn>	No idd write sno
Dec 02 11:22:42 <Seldaek>	which makes me think btw fabpot that if the view thing is merged, imo the magic templatename.format.twig thing should be dropped
Dec 02 11:22:43 <henrikbjorn>	Write a specific templating engine
Dec 02 11:22:44 <lsmith>	also the view layer makes it possible to by pass templates, which is the default for xml/json
Dec 02 11:23:10 <fabpot>	Seldaek: nope, remember that this "thing" should be optional
Dec 02 11:23:19 <henrikbjorn>	You still can just render your response without the templating engine
Dec 02 11:23:21 *	lsmith nods to fabpot
Dec 02 11:23:37 <kriswallsmith>	i'm leery of adding another layer in general, but it sounds like a service we would call from a controller?
Dec 02 11:23:42 <jmikola|w>	Seldaek: also, twig wouldn't be a request format :)  choosing the template language (php or twig for now) is different than deciding to send back xml/json
Dec 02 11:23:52 <lsmith>	that being said .. i have seen this "magic" be a major wtf .. we need to put it in many bold letters what is the implication of _format in a route
Dec 02 11:23:53 <kriswallsmith>	$this->view->render(...
Dec 02 11:23:57 <jmikola|w>	kriswallsmith: it's probably just show up on the return lines of controllers
Dec 02 11:24:06 <jmikola|w>	if you want to add logic to a redirect or render call
Dec 02 11:24:07 <kriswallsmith>	return $this->view->render
Dec 02 11:24:18 <kriswallsmith>	ok
Dec 02 11:24:22 <lsmith>	kriswallsmith: in terms of API .. there is no additional effort a developer has to make
Dec 02 11:24:29 <lsmith>	its just like before
Dec 02 11:24:38 <henrikbjorn>	Except its not
Dec 02 11:25:03 <Seldaek>	the problem I see with the current template name magic is that if you try to generate html via a template in the transformJson method, you'll have to specify templatename.html.twig
Dec 02 11:25:07 <jmikola|w>	henrikbjorn: you could still have the controller call $this->render() or $this->redirect() - i don't see the view requiring explicit mention in your code
Dec 02 11:25:42 <jmikola|w>	lsmith: and what about the controversy of redirect methods, and being able to discern internal from off-site
Dec 02 11:25:48 <henrikbjorn>	If the view layer is used in the base controller render it gets used
Dec 02 11:26:08 <lsmith>	jmikola|w: for now Seldaek and i dropped the idea .. aka we will just implement it in a class that extends the default view
Dec 02 11:26:17 <jmikola|w>	henrikbjorn: yes, under the bonnet, but it's likely just relocated code from the base controller class
Dec 02 11:26:34 <Seldaek>	henrikbjorn: look at this please https://gist.github.com/725605
Dec 02 11:26:36 <lsmith>	given that we now have one method to redirect to a uri and one to redirect to a route .. its doable in a fairly clean wat
Dec 02 11:26:38 <lsmith>	way
Dec 02 11:26:39 <jmikola|w>	henrikbjorn: fabpot was quite adamant about keeping the view light, if it even exists at all :)
Dec 02 11:26:45 <lsmith>	ok .. 4 more minutes on this topic
Dec 02 11:26:51 <avalanche123>	the major addition I like from View is redirectRoute redirectUrl stuff
Dec 02 11:26:54 <henrikbjorn>	What if i still want to have my action render the json template the view layer will ignore that and handle the request itself
Dec 02 11:27:16 <lsmith>	avalanche123: well we could get without the view layer :)
Dec 02 11:27:21 <lsmith>	+that
Dec 02 11:27:33 <avalanche123>	but the View brought it to live:)
Dec 02 11:27:35 <jmikola|w>	avalanche123: +1 - as a familiar convenience for symfony1 users, being able to redirect to a route is helpful (saves the calls to generateUrl() with a final absolute=true param)
Dec 02 11:27:55 <yclian>	I extended sfExecutionFilter for the same reason. u dont want to do it in controller sometimes. u need an extra layer (sometimes)
Dec 02 11:28:02 <lsmith>	henrikbjorn: entirely possible .. the view layer isnt required to be used at all
Dec 02 11:28:04 <jmikola|w>	and the extra method name is needed so we don't do flexible params, like all the sf1 routing functions
Dec 02 11:28:09 <lsmith>	you can work with the templating directly
Dec 02 11:28:37 <Seldaek>	henrikbjorn: if you want a template in a json response you can just extend the view class, override transformJson, and render your html template in there, then return a properly json_encoded thingy
Dec 02 11:28:45 <lsmith>	so its truely optional ... but used by default if you use the Controller help methods
Dec 02 11:28:57 <Seldaek>	or you can just render an html response if you really want that'll return json_encode of an include or something
Dec 02 11:29:02 <Seldaek>	but imo that's ugly
Dec 02 11:29:07 <lsmith>	ok .. lets wrap up ..
Dec 02 11:29:11 *	ce_afk is now known as cescalante
Dec 02 11:29:20 <henrikbjorn>	Exactly i have to override stuff
Dec 02 11:29:21 <lsmith>	as i said before .. this was mainly an opportunity to keep the discussion moving
Dec 02 11:29:48 <Seldaek>	henrikbjorn: so what? in Agavi you don't have to override you have to implement it yourself every time.. With our approach you get nice defaults and just override for specific cases
Dec 02 11:29:54 <lsmith>	henrikbjorn: in your controller you can still do $this->container->get('templating')->render..
Dec 02 11:30:09 <henrikbjorn>	You can just return json encode from a template or with setcontent on the request object
Dec 02 11:30:13 <lsmith>	next topic
Dec 02 11:30:14 <lsmith>	ZF2 dependency: http://bit.ly/hR8awY
Dec 02 11:30:20 <Seldaek>	henrikbjorn: we'll talk later
Dec 02 11:30:24 <lsmith>	arg shit
Dec 02 11:30:33 <lsmith>	where is the email from matthew?
Dec 02 11:30:49 <Seldaek>	lsmith: second mail "show quoted text" ?
Dec 02 11:30:58 <lsmith>	ah :)
Dec 02 11:31:22 <lsmith>	the issue is that right now core only depends on Zend\Log
Dec 02 11:31:34 <lsmith>	and if i understood fabpot correctly .. this is also the plan for the final release
Dec 02 11:31:39 *	bschussek has quit (Ping timeout: 265 seconds)
Dec 02 11:31:48 <lsmith>	so its questionable to be putting a dependency on the gigantic ZF repo
Dec 02 11:31:57 <lsmith>	especially since it has all the demo's and documentation in there too
Dec 02 11:32:14 <lsmith>	Matthew seems to be working on a solution however as it seems
Dec 02 11:32:24 <lsmith>	not sure if anyone has experience with git-subtree
Dec 02 11:32:33 <lsmith>	or if there is anything further to disuss
Dec 02 11:32:35 <fabpot>	lsmith: right now, we don't have anything on the packaging/installation side
Dec 02 11:32:35 <Seldaek>	I don't think we should bother for now
Dec 02 11:32:46 <fabpot>	Seldaek: exactly
Dec 02 11:33:01 <fabpot>	I have played with git-subtree and git-submodules a lot
Dec 02 11:33:02 <jmikola|w>	lsmith: i saw the ZF lead's reply to your mailing list post, so i'd investigate git-subtree and hold on this
Dec 02 11:33:09 <Seldaek>	matthew said ZF will provide something in their final release
Dec 02 11:33:15 <henrikbjorn>	Yes lets see what the zg guys does and if its still a problem bundle with zend log only
Dec 02 11:33:18 <fabpot>	they both have pros and cons, but I think it's too early for now as people should really use the sandbox for now
Dec 02 11:33:21 <jmikola|w>	fabpot: did you earlier mention that ZF log wouldn't even be a dep?
Dec 02 11:33:22 <lsmith>	ZF2 final will come after Symfony2 however ..
Dec 02 11:33:41 <jmikola|w>	or *just* ZF log
Dec 02 11:33:51 <fabpot>	jmikola|w: As lsmith said, if we only rely on Zend Log, perhaps we should drop that dependency altogether
Dec 02 11:33:53 <lsmith>	i guess for now there is https://github.com/weierophinney/zf2/tree/zf2/zend_log
Dec 02 11:34:10 <Seldaek>	fabpot: I'd be +1 on that
Dec 02 11:34:24 <yclian>	will sparse checkout be a solution?
Dec 02 11:34:27 <Seldaek>	ZF taking 90% of my src folder doesn't make me too happy
Dec 02 11:34:36 *	rooster ([email protected]) has joined #symfony-dev
Dec 02 11:34:42 <avalanche123>	so just hard copy Zend\Log and get rid of the rest?
Dec 02 11:34:49 <lsmith>	Seldaek: well with the above linked repo .. you could just get zend\log
Dec 02 11:34:53 <jmikola|w>	Seldaek: even more a problem for folks with IDE's that index source code :)
Dec 02 11:34:54 <Seldaek>	avalanche123: yeah well that's what I did
Dec 02 11:34:57 <fabpot>	avalanche123: that's what we do in the sandbox
Dec 02 11:35:00 <henrikbjorn>	Wouldnt a dep likr zend just be the files a given developer needs and not the whole rep
Dec 02 11:35:05 <avalanche123>	gotcha, that's cool
Dec 02 11:35:14 <avalanche123>	I wouldn't re-invent the logging
Dec 02 11:35:14 *	xdissent ([email protected]) has joined #symfony-dev
Dec 02 11:35:20 <avalanche123>	zf does well there
Dec 02 11:35:36 *	bschussek ([email protected]) has joined #symfony-dev
Dec 02 11:35:48 <jmikola|w>	avalanche123: i think if we solve this, it paves the way for cross-framework code-sharing
Dec 02 11:35:49 <fabpot>	so, should we put that topic on hold for now
Dec 02 11:36:04 <avalanche123>	fabpot +1
Dec 02 11:36:07 <avalanche123>	too early
Dec 02 11:36:15 <fabpot>	jmikola|w: but this is really independent from Symfony or Zend Framework
Dec 02 11:36:16 <avalanche123>	jmikola yeah, understood
Dec 02 11:36:27 <lsmith>	ok .. lets move on then
Dec 02 11:36:27 <henrikbjorn>	Another issue is what if zf wants to use a component?
Dec 02 11:36:32 <fabpot>	unfortunately, Pyrus does not solve this well
Dec 02 11:36:44 <jmikola|w>	fabpot: indeed, but someone has to take initiative to cooperate :D
Dec 02 11:36:46 <avalanche123>	we need to rewrite PEAR!!!
Dec 02 11:36:47 <avalanche123>	:)
Dec 02 11:36:53 <avalanche123>	again...
Dec 02 11:36:59 <lsmith>	avalanche123: PEAR rewrite is called Pyrus
Dec 02 11:37:06 <lsmith>	ok next topic?
Dec 02 11:37:08 <xdissent>	call it Prius this time. wait..
Dec 02 11:37:09 <jmikola|w>	next topic: rewriting PEAR
Dec 02 11:37:22 <avalanche123>	lol
Dec 02 11:37:32 <jmikola|w>	sorry... lsmith ?
Dec 02 11:37:38 <lsmith>	Swiftmailer initialization: http://bit.ly/gsuCmf
Dec 02 11:37:39 <Seldaek>	jmikola|w: if we do that, the next topic must be forking php
Dec 02 11:38:10 <lsmith>	i guess i should start at the beginning on this one
Dec 02 11:38:11 <lsmith>	https://github.com/swiftmailer/swiftmailer/pull/2
Dec 02 11:38:11 <avalanche123>	lsmith, fabpot, how about rewriting it to use symfony DIC?
Dec 02 11:38:30 <jmikola|w>	avalanche123: SM doesn't require php5.3
Dec 02 11:38:37 <lsmith>	the main purpose of that pull request was to prevent users from shooting themselves in the foot
Dec 02 11:38:46 <lsmith>	by trying to make a new Swift_Message instance
Dec 02 11:38:49 <fabpot>	avalanche123: jmikola|w: ... and I just don't have time for that
Dec 02 11:38:52 <henrikbjorn>	I just overwrote the swiftmessage constructor and added a configure method
Dec 02 11:39:04 <avalanche123>	fabpot, yeah, that's understandable
Dec 02 11:39:09 <lsmith>	before they have loaded the mailer for the first time, because only then will swift mailer be initialized
Dec 02 11:39:14 <jmikola|w>	so we're clear, SM's DIC is not even related to the one on symfony-components, correct?
Dec 02 11:39:16 <jmikola|w>	it's all custom?
Dec 02 11:39:23 <lsmith>	however if you dont inject the container ..
Dec 02 11:39:29 <avalanche123>	I agree with lsmith there, except I would change the method name to getMessage or newMessage or createMessage
Dec 02 11:39:33 <fabpot>	jmikola|w: correct
Dec 02 11:39:33 <avalanche123>	since its not a service
Dec 02 11:39:38 <lsmith>	and instead inject instances, then you always initialize the swift mailer
Dec 02 11:39:41 <lsmith>	which is very heavy
Dec 02 11:39:51 <kriswallsmith>	I've added a non-shared new_message service that includes the init file as well
Dec 02 11:40:09 <lsmith>	so to me the initialization issue could be solved two ways:
Dec 02 11:40:19 <lsmith>	1) a rewrite to the SF2 DIC
Dec 02 11:40:22 <lsmith>	2) a wrapper
Dec 02 11:40:26 <lsmith>	2) seems more feasible
Dec 02 11:40:28 <jmikola|w>	kriswallsmith: link?
Dec 02 11:40:32 <lsmith>	unless someone steps up for 1)
Dec 02 11:40:53 <kriswallsmith>	jmikola|w: sure, i'll bake something up…
Dec 02 11:40:54 <avalanche123>	at some point in future, lsmith
Dec 02 11:40:54 <fabpot>	lsmith: I'm not sure I understand the initialization issue
Dec 02 11:41:00 <jmikola|w>	kriswallsmith: oh i thought it was already in git :)
Dec 02 11:41:08 <lsmith>	fabpot: if i inject the service but do not use it
Dec 02 11:41:13 <lsmith>	its very heavy
Dec 02 11:41:27 <avalanche123>	fabpot - if you call Message::getInstance() before $container->get('swift.mailer') - it breaks
Dec 02 11:41:27 <jmikola|w>	lsmith: but you need it to make messages is the problem?
Dec 02 11:41:37 <fabpot>	avalanche123: I know
Dec 02 11:41:39 <lsmith>	jmikola|w: sorry if i was unclear
Dec 02 11:41:51 <fabpot>	lsmith: what do you inject where?
Dec 02 11:41:53 <lsmith>	issue I) is solved by the pull request
Dec 02 11:42:14 <lsmith>	issue II) i discovered while doing the fix .. and that is that its very expensive to make an instance of the mailer service
Dec 02 11:42:27 <lsmith>	fabpot: if i inject a mailer instance into my controller
Dec 02 11:42:33 <lsmith>	then swift init is done
Dec 02 11:42:44 <Seldaek>	fabpot: as you know, we inject controllers and don't use the magic routing thingy with the injected container
Dec 02 11:42:49 <lsmith>	of course if i do not inject the mailer .. but instead inject the container .. then this is a non issue
Dec 02 11:42:50 <Seldaek>	so we need light dependencies
Dec 02 11:43:14 <jmikola|w>	lsmith: ah, i follow now
Dec 02 11:43:18 <fabpot>	lsmith: ok, so this is not related to the pull request, right?
Dec 02 11:43:34 <lsmith>	fabpot: no .. its related to my last comment .. sorry i was not clear on the topic
Dec 02 11:43:41 <fabpot>	lsmith: I get it now
Dec 02 11:43:47 <jmikola|w>	so calling setMailer() on your service controller involves initializing mailer, even if the action that executes might not use mailer
Dec 02 11:43:47 <lsmith>	https://github.com/swiftmailer/swiftmailer/pull/2#issuecomment-572242
Dec 02 11:43:49 <fabpot>	we can do what I've done with the routing loader
Dec 02 11:43:56 <lsmith>	jmikola|w: right
Dec 02 11:44:09 <avalanche123>	lazy wrapper
Dec 02 11:44:11 <avalanche123>	fabpot +1
Dec 02 11:44:17 <fabpot>	I have created a LazyLoader, which is just a proxy
Dec 02 11:44:22 <kriswallsmith>	jmikola|w: https://gist.github.com/725636
Dec 02 11:44:23 <jmikola|w>	+1 to that
Dec 02 11:44:26 <lsmith>	fabpot: yeah .. that will do
Dec 02 11:44:28 <fabpot>	the proxy knows about the container and creates the mailer
Dec 02 11:44:34 <kriswallsmith>	oops, adding the file
Dec 02 11:44:40 <jmikola|w>	fabpot: lazyLoader is specific to mailer, or it's for any service?
Dec 02 11:44:51 <fabpot>	jmikola|w: just for the loader
Dec 02 11:44:57 <lsmith>	in general .. we should make sure that all core services are "light", lazy connecting, lazy initializing
Dec 02 11:45:10 <lsmith>	and apply proxy wrappers where ever this is not reasily possible
Dec 02 11:45:12 <lsmith>	imho
Dec 02 11:45:15 <fabpot>	lsmith: I've worked on that already. I might have missed some, but I don't think so
Dec 02 11:45:22 <Seldaek>	in general yes, you should do no work in constructors
Dec 02 11:45:26 <lsmith>	not sure if there are any other core services that are problematic besides the swift mailer
Dec 02 11:45:31 <lsmith>	fabpot: ok great
Dec 02 11:45:47 <jmikola|w>	kriswallsmith: this is from our factory-method discovery :)   it solves the problem, but bulat has the complaint that message isn't a service :)
Dec 02 11:46:00 <avalanche123>	yup, I do:)
Dec 02 11:46:09 <fabpot>	avalanche123: and you are right
Dec 02 11:46:20 <avalanche123>	thanks fabpot
Dec 02 11:46:22 <lsmith>	ok .. the last topic was a stupid idea from me to even put on the list .. aka chunked responses with esi ..
Dec 02 11:46:23 <fabpot>	and lsmith pull request "fixes" the issue better
Dec 02 11:46:24 <jmikola|w>	this is like using the container as a generic builder :)
Dec 02 11:46:29 <avalanche123>	agreed
Dec 02 11:46:36 <avalanche123>	but method name should be changed
Dec 02 11:46:44 <jmikola|w>	lsmith: that's the topic from gblanco?
Dec 02 11:46:48 <fabpot>	avalanche123: understood ;)
Dec 02 11:46:54 <lsmith>	liip will be looking at varnish closely
Dec 02 11:47:07 <lsmith>	and will look at their work towards adding streaming support
Dec 02 11:47:29 <lsmith>	btw .. here is their shopping list for the next major version http://www.varnish-cache.org/trac/wiki/PostTwoShoppingList
Dec 02 11:47:42 <lsmith>	the ground work will be 3.0 to be released in january .. streaming should come in 3.1
Dec 02 11:47:59 <lsmith>	ok .. then we have all the topics?
Dec 02 11:48:10 <lsmith>	any topic i should have had on the list?
Dec 02 11:48:19 <lsmith>	that could be discussed now quick;y
Dec 02 11:48:26 <lsmith>	otherwise .. we would be at the end
Dec 02 11:49:24 <Seldaek>	guess that concludes it :p
Dec 02 11:49:29 <avalanche123>	:)