You must first sign up to be able to contribute.


Custom loader resources notation

Fabien explained the choices and made it clear that the final solution needs to maintain extensibility and use the same structure for all formats. In the end it was agreed that Jeremy will implement a solution where a new optional "loader" (defaults to "file") attribute is introduced to determine the loader to use.

View layer

This was a fairly lengthy discussion. Mainly Henrik was questioning the relevance of this additional layer, since everything could just as well be written into the controller. Thomas replied "the view layer is great if you want to output json, amf, xml or html with the same action". Jordi added that this would be possible without "format-specific logic" in the controller. Also while one can generate json via twig, it will not be possible to generate PDF or AMF via the template layer in a sensible manner. Finally it was noted that the view layer is optional and can be by passed. Bulat said that he really appreciates the new method to redirect to a route instead of only an url. Jordi raised the question if the "twig magic" of choosing a file based on the _format when no format is specified explicitly in the template logic name is still needed in light of the view layer. The discussion will continue on the topic. Fabien also needs more time to review the layer in detail.

ZF2 dependency

Matthew from the Zend Framework team has send a proposal for how to be able to just fetch the Zend\Log dependency via git and he is committed to making a rock solid solution. In light of this it was decided to hold off from trying to also work on a solution. However the question was also raised if it even makes sense to depend on Zend\Log at all. But again it was decided to wait.

Swiftmailer initialization

The discussion revolved about addressing two issues: 1) preventing issues where Swift_Message would not be available until the mailer service is instantiated. There is already a pull request ready for this. 2) that at instantiation of the swift mailer is initialized which is very expensive, which in turn is not ideal when a controller gets the mailer injected explicitly in cases where the mailer is optional for the controller. Bulat suggested a rewrite of swift mailer on top of the Symfony2 DIC, however as nobody stepped up to take this on it was decided to rather use a proxy wrapper to delay initialization as long as possible. In general Fabien stated that its the intention to have all core services be lazy loading as much as possible.

Chunked responses and ESI

Here Lukas just briefly informed everyone that its too early to get into details here as any solution should follow what Varnish is doing. However they currently do not support chunked (streaming) in combination with ESI. Varnish 3.0 planned for January 2011 will lay the ground work and streaming is expected to follow in 3.1.

IRC logs

Dec 02 11:00:45 <lsmith>	ok let goo
Dec 02 11:00:59 <lsmith>	first topic is Custom loader resources notation:
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
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 (~bschussek@ 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
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
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:
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__ ( 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:
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
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:
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
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 ( 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 ( has joined #symfony-dev
Dec 02 11:35:20 <avalanche123>	zf does well there
Dec 02 11:35:36 *	bschussek (~bschussek@ 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:
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>
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>
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:
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
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>	:)