[2011-12-09 18::06:50] Crell: I've an architectural question if anyone has a moment.

  [2011-12-09 18::07:32] Stof: Crell: shoot

  [2011-12-09 18::07:49] couac: thanks!

  [2011-12-09 18::08:05] Crell: The stuff I've seen on Symfony makes a big deal about how it doesn't do application caching, and just "lets HTTP do it".

  [2011-12-09 18::08:30] couac: Stof: oh and I'm ok with your conclusion (about the end of the proxy)

  [2011-12-09 18::08:35] Crell: Doesn't that mean that you cannot control when newly posted content is available? You cannot say "this object has changed, so next time it's requested regenerate the page and recache"?

  [2011-12-09 18::09:29] » couac left the chat room.

  [2011-12-09 18::10:14] Stof: Crell: lsmith wants to build such a tool using advanced features provided by Varnish to invalidate the cache selectively

  [2011-12-09 18::10:43] pounard: If I remember well, Plone does it

  [2011-12-09 18::11:38] Crell: pounard: Ohhai. :-)

  [2011-12-09 18::11:39] Stof: Crell: http://pooteeweet.org/blog/1979

  [2011-12-09 18::11:43] » damcgn joined the chat room.

  [2011-12-09 18::11:50] DrRotmos: Crell: there are three basic approaches to caching: expiration, validation and invalidation, the HTTP protocol has direct support for 1 and 2, for number 3 you need to do more stuff :)

  [2011-12-09 18::12:02] Crell: Stof: So the answer is "yeah that's a problem, lsmith wants to solve it"? :-)

  [2011-12-09 18::12:13] Stof: yeah

  [2011-12-09 18::12:20] DrRotmos: to be honest, invalidation is a pain in the ass

  [2011-12-09 18::12:25] Crell: is thinking of Drupal in particular, where we have a page cache built in.

  [2011-12-09 18::12:53] pounard: DrRotmos> yes it is

  [2011-12-09 18::13:30] Stof: Crell: if you are caching the output to disk, you have the same issue to invalidate all pages using a given content

  [2011-12-09 18::14:14] DrRotmos: of course

  [2011-12-09 18::14:17] Crell: Yes.

  [2011-12-09 18::15:01] pounard: cache tags

  [2011-12-09 18::15:07] Stof: well, then it's not really an issue either: send a PURGE request to varnish for the primary url

  [2011-12-09 18::15:14] pounard: really efficient solution, imho, but not every backend supports it well

  [2011-12-09 18::15:17] Crell: That assumes you have varnish.

  [2011-12-09 18::15:37] Stof: well, other http cache probably support a way to invalidate them

  [2011-12-09 18::15:37] pounard: s/well//

  [2011-12-09 18::15:38] Crell: Many sites don't, and authenticated users generally don't (in Drupal's current implementation).

  [2011-12-09 18::16:11] Stof: ah, if you mean the browser cache, you can indeed not invalidate it

  [2011-12-09 18::16:28] Crell: Er, no.

  [2011-12-09 18::16:45] Stof: Crell: Symfony2 implements a proxy cache in PHP in the HttpKernel component :)

  [2011-12-09 18::16:46] pounard: you can send a javascript alert("please click ctrl + reload"); via some ajax polling system

  [2011-12-09 18::17:17] Crell: Right now, Drupal always sends a cache invalidation timestamp in the past. It then has its own appplication-level page cache (backed by the DB, memcache, or whatever you want).

  [2011-12-09 18::17:20] Stof: not as efficient as Varnish of course (as it is hitting apache and PHP first) but usable on shared hostings :)

  [2011-12-09 18::17:45] Crell: That ensures that it has full control over the page update time.

  [2011-12-09 18::17:48] DrRotmos: Stof: also, it allows for ESI

  [2011-12-09 18::17:56] Stof: yep, but Varnish too

  [2011-12-09 18::17:59] DrRotmos: sure

  [2011-12-09 18::18:24] Crell: If you have Varnish, you disable that and Varnish takes over, at the expense of not being able to force a cache clear (currently), so you just set the lifetime to a few minutes.

  [2011-12-09 18::19:05] Stof: so when using Varnish, no need for HttpCache

  [2011-12-09 18::19:05] DrRotmos: (although varnish doesn't support stale-while-revalidate, which is a shame, but that's another thing :) )

  [2011-12-09 18::19:05] pounard: You can still force cache clear with PURGE I guess

  [2011-12-09 18::19:21] Stof: Crell: btw, I think it is possible to implement an output cache in Symfony2 if you really need it, by using a response listener to cache and a request listener to set the response early when available

  [2011-12-09 18::19:38] Crell: does not full follow that statement.

  [2011-12-09 18::19:59] DrRotmos: Stof: but that's just unnecessary?

  [2011-12-09 18::20:15] pounard: Stof> that's almost what Drupal does

  [2011-12-09 18::20:19] Stof: DrRotmos: I said "if you really need it"

  [2011-12-09 18::20:23] DrRotmos: if you need an output cache, you can just use the HttpCache

  [2011-12-09 18::20:29] Stof: an http cache would be better indeed

  [2011-12-09 18::20:41] Crell: An HTTP Cache internal to the application layer?

  [2011-12-09 18::21:03] Stof: Crell: the HttpCache is not inside the application layer but around it

  [2011-12-09 18::21:19] » drak joined the chat room.

  [2011-12-09 18::21:20] Crell: But in PHP, I mean.

  [2011-12-09 18::21:25] Stof: it is a special kernel wrapping the standard one

  [2011-12-09 18::21:34] Crell: still hasn't spent the necessary 20 hours digging through Symfony core to grok it.

  [2011-12-09 18::21:41] Stof: so if it has the cached response, he sends it directly

  [2011-12-09 18::22:57] Crell: Also on my list.

  [2011-12-09 18::23:16] Stof: Symfony2 builds lots on top of that (and uses the extended Kernel, not only the simple HttpKernel) so it is more complex

  [2011-12-09 18::23:20] Crell: I know HttpKernel is designed to be infinitely stackable. How far down does that go, though?

  [2011-12-09 18::24:39] Stof: look at the HttpKernel section in this blog post: http://fabien.potencier.org/article/49/what-is-symfony2

  [2011-12-09 18::25:11] Crell: I think I've seen that a few times. :-)

  [2011-12-09 18::25:44] Stof: well, you already use the Request, no ?

  [2011-12-09 18::26:28] Crell: Well... we have it in the repo. The code to actually leverage it hasn't merged yet. :-)

  [2011-12-09 18::26:57] Stof: do you need a different implementation (assuming we have an interface with the current implementation) ?

  [2011-12-09 18::27:07] Crell: But, our plan was that the request would only be one part of an extended "context" object, which included the request as well as other application-level things that depend on it, like the active user object, the "current" node (if any), etc.

  [2011-12-09 18::27:34] DrRotmos: that's… contrary to the purpose of the request object :)

  [2011-12-09 18::27:35] Stof: hmm, btw, simply adding an interface is not possible as the interface cannot enforce the public properties used currently...

  [2011-12-09 18::27:52] Crell: DrRotmos: Please explain.

  [2011-12-09 18::28:07] Stof: Crell: the current node could be an attribute of the request

  [2011-12-09 18::28:36] Crell: The current node is *usually* the result of a node_load() call on the second argument of the path, if the first argument is "node".

  [2011-12-09 18::29:01] DrRotmos: Crell: the Request class represents an HTTP request, since HTTP is a request/response protocol, there is no overlying context to it

  [2011-12-09 18::29:17] Crell: However, we also want to have individual chunks of the page, blocks, be able to accept a node as current from anywhere else without knowing. Basically the current implementation of the context object is rather Pimple-like.

  [2011-12-09 18::30:27] » drak left the chat room.

  [2011-12-09 18::30:34] Stof: Crell: the kernel is meant to be the entry point of the app (called in the front controller). Determining the current node would be done by some logic triggered inside handle() IMO, not before calling it

  [2011-12-09 18::31:05] Crell: Hence my question, since that implies that we then cannot also use it for those individual blocks.

  [2011-12-09 18::31:23] Stof: Crell: if you are using ESI, you cannot pass objects to your block. The cache will only be able to trigger an url, not to pass them

  [2011-12-09 18::31:33] Crell: The appropriate controller, or controller/configuration, for a given request may depend on the node.

  [2011-12-09 18::31:50] Stof: you can load the node before choosing the controller

  [2011-12-09 18::31:51] Crell: That's something we support now via add-on modules in a sucky way.

  [2011-12-09 18::32:12] DrRotmos: Crell: what you're saying is that the controller depends on the node, which in turn depends on the request, right?

  [2011-12-09 18::32:19] Crell: Right.

  [2011-12-09 18::32:23] Stof: in Symfony, the controller depends of the route, which is determined based on the request

  [2011-12-09 18::32:29] DrRotmos: take a look at the CMS routing bundle

  [2011-12-09 18::32:30] Crell: So perhaps I'm conflating the kernel and router.

  [2011-12-09 18::32:45] DrRotmos: sorry, CMF routing bundle

  [2011-12-09 18::32:51] Stof: DrRotmos: no need for it

  [2011-12-09 18::33:13] DrRotmos: Stof: if he wants to do routing to different controllers depending on some domain object, he should use it

  [2011-12-09 18::33:15] Crell: Which Drupal is not using at present.

  [2011-12-09 18::33:16] Stof: it's not the first thing to look at to understand routing

  [2011-12-09 18::33:37] DrRotmos: Stof: it's not just for PHPCR, I should know, I wrote the first iteration of the code :)

  [2011-12-09 18::34:56] Stof: ah indeed, it is a DoctrineRouter

  [2011-12-09 18::35:17] DrRotmos: Stof: the built in routing system is great if you can deduce which controller to use depending only on the request object, but if you depend on a domain object as well, you need to extend it somehow

  [2011-12-09 18::36:05] Stof: Crell: HttpKernel has a ControllerResolver which chooses the controller based on the _controller attribute of the request (and different implementation could use additional stuff)

  [2011-12-09 18::36:07] DrRotmos: so and while it ships with a DoctrineRouter, you can write your own router and inject it in the chain

  [2011-12-09 18::36:25] Stof: but it does not bother about the way you fill the _controller attribute

  [2011-12-09 18::36:54] Crell: Right, that's one of the things that concerns me.

  [2011-12-09 18::37:04] Stof: but you can use a different way to fill it

  [2011-12-09 18::37:22] Crell: All of the examples I've seen of using the routing system are not going to scale to the number of routes that Drupal has to support.

  [2011-12-09 18::37:22] Stof: simply use a different listener to populate the attribute (one that you wrote)

  [2011-12-09 18::37:39] Crell: Unless that's just "demos are too simple to be useful". :-)

  [2011-12-09 18::37:49] Stof: HttpKernel dependency to Routing is only an optional one

  [2011-12-09 18::40:46] pounard: Good night all

  [2011-12-09 18::48:43] » krymen joined the chat room.

  [2011-12-09 18::50:21] » rooster left the chat room.

  [2011-12-09 18::59:58] Crell: Stof: So, let me ask this.

  [2011-12-09 19::04:01] » danielcsgomes left the chat room.

  [2011-12-09 19::05:54] Stof: yeah

  [2011-12-09 19::06:41] Crell: Please elaborate. :-)

  [2011-12-09 19::06:50] Stof: but keep in mind that rendering something by ESI means that the proxy cache will do another request for the ESI block. so the block needs to be represented by a single url

  [2011-12-09 19::07:00] Crell: Right.

  [2011-12-09 19::07:02] Stof: not by a complex PHP object

  [2011-12-09 19::07:48] Crell: So how would you go about injecting more detailed information than just the request object itself?

  [2011-12-09 19::08:29] Stof: injecting it for what and where ?

  [2011-12-09 19::08:54] Crell: A given block renders a node, in a given form.

  [2011-12-09 19::09:53] Stof: btw, this can be a place for Routing, with a route /node/{node_id} :p

  [2011-12-09 19::09:54] Crell: Our thinking so far has been that the context object is serializable, so the ESI path that is generated includes the necessary information in GET parameters.

  [2011-12-09 19::10:06] Stof: Crell: the ESI url needs to include it

  [2011-12-09 19::10:08] Crell: I figured. :-) We have a routing system now.

  [2011-12-09 19::10:46] Stof: when doing ESI in Symfony2, the generated url includes a bunch of GET parameters

  [2011-12-09 19::11:12] Crell: Whatever. :-)

  [2011-12-09 19::11:45] Stof: let me write some code in a gist about the way HttpKernel could be used

  [2011-12-09 19::11:50] Crell: OK, thanks.

  [2011-12-09 19::12:59] Stof: hmm, just to be sure. Do you need the node object to choose the controller or just its id ?

  [2011-12-09 19::13:07] Crell: Potentially we need the node object.

  [2011-12-09 19::13:15] Stof: I can provide 2 examples so I need to choose the good one :)

  [2011-12-09 19::13:18] Crell: Because two different node types could have vastly different layouts.

  [2011-12-09 19::13:50] » jstout left the chat room.

  [2011-12-09 19::13:51] Crell: (See why I struggle with this problem space? <g>)

  [2011-12-09 19::32:11] Stof: quite done

  [2011-12-09 19::32:32] Crell: Cool. :-)

  [2011-12-09 19::35:07] » notjosh left the chat room.

  [2011-12-09 19::37:31] » krymen left the chat room.

  [2011-12-09 19::38:17] Stof: https://gist.github.com/1454212

  [2011-12-09 19::39:51] Crell: Looking now...

  [2011-12-09 19::41:19] Stof: note that my current example integrates the Symfony routing to match the elements of the url (the node id in my case) but it could be another system as long as the listener using it sets the param in the Request before DrupalNodeListener

  [2011-12-09 19::42:50] Crell: The current Drupal solution is path matching with infix variables against a denormalized path SQL table.

  [2011-12-09 19::43:31] Stof: well, the matching to SQL is what is done in DrupalNodeListener

  [2011-12-09 19::44:02] Crell: So if we had node/nid, and user/uid, and /some/form/goes/here/damnit, those would all be different listeners?

  [2011-12-09 19::44:22] Stof: what the routing does in my case is extracting node_id from the url

  [2011-12-09 19::44:56] Crell: sees the word RequestContext and cries at the noun collision... :-)

  [2011-12-09 19::45:15] Stof: Crell: no name collision because a class name includes the namespace

  [2011-12-09 19::45:26] Crell: No, I mean conceptually with what we've been calling "Context".

  [2011-12-09 19::45:35] Stof: I simply omitted them there because of lazyness

  [2011-12-09 19::46:08] Crell: What is that, exactly?

  [2011-12-09 19::46:08] Stof: even a Symfony user does not see it

  [2011-12-09 19::46:37] Crell: (If there's some sort of deep dive documentation on this stuff already beyond fabpot's blog post I should be reading instead, please point me to it.)

  [2011-12-09 19::46:51] Stof: an object holding values representing the request for the router: host, base_path, path_info...

  [2011-12-09 19::47:09] Crell: blinks.

  [2011-12-09 19::47:15] Stof: and some parameters that can be used when generating an url without having to pass it

  [2011-12-09 19::47:15] Crell: So it's an "enhanced request object"?

  [2011-12-09 19::47:24] Stof: no, a specialized one

  [2011-12-09 19::47:26] DrRotmos: more like a stripped down

  [2011-12-09 19::47:40] Stof: containing only stuff needed to match a route

  [2011-12-09 19::48:06] Crell: Which in Drupal's case could be a variety of things.

  [2011-12-09 19::48:34] Stof: Crell: not really. the RequestContext does not define the different routers

  [2011-12-09 19::49:33] Crell: That is more or less than what is in HttpFoundation\Request?

  [2011-12-09 19::49:47] Stof: a subset of it

  [2011-12-09 19::49:59] Crell: How is that subset selected?

  [2011-12-09 19::50:13] Stof: route matching is about the path info, so no need of GET, POST and FILES parameters for instance

  [2011-12-09 19::50:34] Crell: What if your route depends on other headers, like accept types or language?

  [2011-12-09 19::51:18] Stof: RequestContext is the Routing component

  [2011-12-09 19::51:35] Crell: :-)

  [2011-12-09 19::52:23] Stof: and I add a typo. using the request at the beginning and creating it at the end :)

  [2011-12-09 19::52:29] Crell: hehehe.

  [2011-12-09 19::53:40] Stof: probably or even use a totally different routing system than the sf2 one if you prefer

  [2011-12-09 19::54:33] Crell: Hm.

  [2011-12-09 19::54:51] Stof: Routing has no dependency (well, an optional one to the Config component to load routes from XML or YAML config files)

  [2011-12-09 19::55:10] Crell: Which we'll likely need, although probably not using the Symfony Config one.

  [2011-12-09 20::00:08] » DrRotmos left the chat room.

  [2011-12-09 20::02:56] Crell: So DrupalNodeListener is the controller that DrupalControllerResolver locates...?

  [2011-12-09 20::03:03] Stof: no

  [2011-12-09 20::03:09] Crell: Damn, missed it again.

  [2011-12-09 20::03:24] Stof: it is the listener responsible to load the node object before the controller is resolved

  [2011-12-09 20::03:47] Crell: Ahhh...

  [2011-12-09 20::03:54] Stof: the kernel.request event is dispatched before choosing the controller (the router also uses it to match the route)

  [2011-12-09 20::04:12] Crell: OK, so in Drupal right now, if you have a path of node/%node/view, then %node maps to node_load($argument_that_was_in_the_path), which returns a node object.

  [2011-12-09 20::04:30] Stof: yes

  [2011-12-09 20::05:03] Crell: And an arbitrary number of those can be registered, so one for nodes, one for user, one for taxonomy term, one for a "view object", etc.

  [2011-12-09 20::05:34] Stof: and ControllerResolver uses the logic you want to retrieve a PHP callable that will return a response

  [2011-12-09 20::06:11] Crell: Will all resolvers fire, or just selected resolvers (somehow)?

  [2011-12-09 20::06:25] » juokaz left the chat room.

  [2011-12-09 20::06:33] Stof: there is only one ControllerResolver in the kernel

  [2011-12-09 20::06:48] Crell: is using the wrong word here...

  [2011-12-09 20::07:15] Stof: but you could implement a chain resolver containing several ones and calling them until one does the job :)

  [2011-12-09 20::07:38] Crell: lsmith has tried to talk my ear off about those but I didn't have the context (no pun intended) to figure out what he was talking about.

  [2011-12-09 20::07:52] Stof: refresh the page

  [2011-12-09 20::07:52] Crell: Oh, reloading...

  [2011-12-09 20::08:49] Stof: yep

  [2011-12-09 20::09:00] Crell: And then DrupalControllerResolver wraps basically our current logic.

  [2011-12-09 20::09:25] Stof: well, to be efficient, line 17 to 33 should be wrapped in another class

  [2011-12-09 20::09:35] Crell: True.

  [2011-12-09 20::09:48] Stof: which also implements the HttpKernelInterface and creates all things only when calling handle() in it

  [2011-12-09 20::10:22] Crell: So class Drupal implements HttpKernelInterface { handle() { That gist } }

  [2011-12-09 20::10:38] Stof: line 17 to 33 yes

  [2011-12-09 20::10:55] Crell: is beginning to understand.

  [2011-12-09 20::11:01] Stof: and then, line 41 $kernel being this class

  [2011-12-09 20::11:22] Crell: lol

  [2011-12-09 20::11:45] Stof: well, copied it at the top and let it at the bottom

  [2011-12-09 20::12:01] Crell: OK, here's where I run into an issue, maybe.

  [2011-12-09 20::12:21] Stof: but if it is created inside Drupal::handle, the request is passed as parameter

  [2011-12-09 20::13:12] Crell: We have a code-time-unknown number of possible listeners.

  [2011-12-09 20::13:38] Stof: simply use a different listener instead of RouterListener to update the attributes of the route with your own router implementation

  [2011-12-09 20::14:09] Crell: The normal Drupal answer to that is a hook, which if you're not familiar with them is a low-level event/pointcut system. Works great aside from the need to have all code loaded at all times so that we can do a function_exists() on it.

  [2011-12-09 20::14:51] Stof: the standard EventDispatcher component requires to create all listeners

  [2011-12-09 20::15:03] Crell: Right.

  [2011-12-09 20::15:16] Stof: FrameworkBundle extends it be able to lazy-load them using the DI container

  [2011-12-09 20::15:23] Crell: The "we have an assload of them and we cannot edit code or do code generation problem" applies to a lot of problems in Drupal. :-)

  [2011-12-09 20::15:45] Stof: you can create your own extended dispatcher with your own way to lazy-load

  [2011-12-09 20::16:25] » noisebleed left the chat room.

  [2011-12-09 20::16:37] Stof: basically, instead of giving the listener, FrameworkBundle adds another method allowing to give the id in the container and the event name

  [2011-12-09 20::16:39] Crell: nods.

  [2011-12-09 20::16:48] » guilhermeblanco joined the chat room.

  [2011-12-09 20::16:56] Stof: and when this event name is dispatched, it loads all listeners for this event

  [2011-12-09 20::17:17] Crell: Container being...?

  [2011-12-09 20::17:23] Stof: clearly useful for events that are not always dispatched (kernel.exception for instance)

  [2011-12-09 20::17:40] Crell: ah

  [2011-12-09 20::18:34] Stof: an extended version could eventually have been written based on Pimple but Silex tried not to do it and to register the listeners directly

  [2011-12-09 20::19:02] Crell: Right, which wouldn't scale for us.

  [2011-12-09 20::20:31] Stof: Crell: copy https://github.com/symfony/FrameworkBundle/blob/master/ContainerAwareEventDispatcher.php using Pimple instead of the Sf2 container :p

  [2011-12-09 20::22:05] Crell: So what we'd need to do is: 1) Write a lazy-loading EventDispatcher; 2) Somehow register an arbitrary number of listeners to add extra stuff to the request object (nodes, users, etc.); 3) Move our existing routing logic into DrupalControllerResolver::getController(); 4) Always return a Response object from anything that getController() says to call; 5) Profit.

  [2011-12-09 20::23:09] Stof: btw, there is a way to return something else from the controller (as long as it is not null)

  [2011-12-09 20::23:42] Crell: ... And then for individual blocks, treat them as a BlockApp class rather than a DrupalApp class that does all the same stuff, but for a different path that we fake before calling that.

  [2011-12-09 20::23:57] Stof: when the return value is not a Response (and only in this case), the kernel dispatches the kernel.view event as a last chance

  [2011-12-09 20::24:17] Crell: Kernel depends on EventDispatcher then?

  [2011-12-09 20::24:21] Stof: yes

  [2011-12-09 20::24:24] Crell: OK.

  [2011-12-09 20::24:41] Stof: well, the EventDispatcher component is 2 classes and 2 interfaces :)

  [2011-12-09 20::24:47] Crell: Big whup.

  [2011-12-09 20::25:12] Stof: the event dispatcher provides hooks in the request handling:

  [2011-12-09 20::27:47] Crell: ... And if we want to explicitly set a given object, such as the node, we could set that on the request object before passing it to the sub-app, and write the listeners to ignore it if it's already there.

  [2011-12-09 20::28:28] Stof: yep, of course

  [2011-12-09 20::30:31] Crell: And... because each request object is potentially created new, we can guarantee that you cannot modify the request information (the "context" in Drupal speak) in one block/subapp and cause a change in another block/subapp.

  [2011-12-09 20::31:11] Stof: hmm, you can change the request object

  [2011-12-09 20::31:35] Crell: OK, that's kinda what I'm after.

  [2011-12-09 20::31:46] Stof: so the subapp will do whatever it wants without impacting the main app

  [2011-12-09 20::32:37] Crell: So... I'm not sure if I should be happy or annoyed that we basically just described 75% of what I'm trying to do in Drupal 8 as "a couple of Symfony subclasses".

  [2011-12-09 20::33:05] Stof: and btw, you can force changing the properties of the Request (GET and so on) when duplicating if you add some parameters

  [2011-12-09 20::33:24] Crell: And the request object can hold arbitrary information. I did not realize that.

  [2011-12-09 20::33:42] Stof: that's what attributes are for

  [2011-12-09 20::34:43] Crell: Right.

  [2011-12-09 20::35:43] Stof: you could indeed wrap the subapps in a cache :p

  [2011-12-09 20::36:36] Crell: Well, what I'm hoping we can do is allow individual blocks to be rendered asynchronously, either within a single request, managed by varnish, or managed by backbone.js in the client.

  [2011-12-09 20::38:48] Stof: Response ?

  [2011-12-09 20::39:09] Crell: Any block could add css files to the page.

  [2011-12-09 20::39:31] Stof: ah, this is a bit tricky about the building of the content

  [2011-12-09 20::39:50] Crell: (Actually right now the page array could add css at virtually any point, which is godawful but there are reasons for it.)

  [2011-12-09 20::40:19] Stof: yeah, I see what can be the advantage for drupal :)

  [2011-12-09 20::40:51] Crell: So you'd create a DrupalResponse object, pass it around, and let anyone call ->addCSS() and ->addJs().

  [2011-12-09 20::41:21] Stof: if the subapp wants to add some of them, it creates a DrupalResponse

  [2011-12-09 20::41:42] Crell: And some other controllers could instead ignore that and return a JSON string.

  [2011-12-09 20::41:45] Stof: and the main app uses them

  [2011-12-09 20::42:07] Crell: I see I have a lot of work to do this weekend.

  [2011-12-09 20::42:34] Stof: Crell: yeah. my idea is similar except that the subapp creates the response itself

  [2011-12-09 20::42:50] Crell: But then how do you merge response objects?

  [2011-12-09 20::42:56] Stof: the main app

  [2011-12-09 20::43:22] Crell: Does the response class have enough getters on it to extract the body and such?

  [2011-12-09 20::43:51] Stof: look at my message above: a subclass with 2 additional getters

  [2011-12-09 20::43:58] Crell: Right.

  [2011-12-09 20::43:58] Stof: yes, it returns

  [2011-12-09 20::44:20] Crell: Which could return as far up a stack of subapps as we want, and the top level one would ->send() instead of returning.

  [2011-12-09 20::44:33] Stof: the top level one also returns

  [2011-12-09 20::44:43] Crell: Ah, OK.

  [2011-12-09 20::44:50] Stof: look at the gist: send is called by index.php

  [2011-12-09 20::45:05] Crell: Ahhh...

  [2011-12-09 20::45:17] Stof: so really at the whole end

  [2011-12-09 20::45:52] Crell: I thought DrupalApp wraps $kernel, and returns a response.

  [2011-12-09 20::46:11] Stof: here is how the index.php could look like: https://github.com/symfony/symfony-standard/blob/master/web/app.php

  [2011-12-09 20::46:28] Crell: Right.

  [2011-12-09 20::46:30] Stof: replace the Sf2 AppKernel by your DrupalKernel and you're done

  [2011-12-09 20::46:55] Crell: nods.

  [2011-12-09 20::47:17] Stof: I will update the gist with a DrupalKernel containing the bootstrapping logic

  [2011-12-09 20::47:32] Crell: Or do we assume that if we wrap each one in a cache object that it will work out in the end?

  [2011-12-09 20::47:39] » tystr left the chat room.

  [2011-12-09 20::47:43] Crell: Does this channel have a karma tracking bot? :-)

  [2011-12-09 20::47:59] Stof: depends if each subapp uses the Sf2 httpKErnel dispatching events or if it simply implements the inetrface

  [2011-12-09 20::48:31] Crell: Well, I definitely at least owe you dinner the next time we're at a conference together. :-)

  [2011-12-09 20::48:39] Stof: but you can go vote on http://awards.symfony.com/ if you want :)

  [2011-12-09 20::48:46] Crell: LOL.

  [2011-12-09 20::49:46] Stof: Crell: no, it mandates it is a kernel

  [2011-12-09 20::49:56] » sirprize joined the chat room.

  [2011-12-09 20::50:00] Stof: not that it uses the HttpKernel implementation internally

  [2011-12-09 20::50:00] Crell: Right, so each block then is doing a full routing lookup.

  [2011-12-09 20::50:17] Stof: no, it can be a simpler kernel

  [2011-12-09 20::50:56] Crell: OK...

  [2011-12-09 20::51:26] Stof: even public function handle($request) { return new Response('useless subapp spotted);}

  [2011-12-09 20::52:36] Crell: But then how does it support block/blockname?nid=5

  [2011-12-09 20::53:11] Stof: Crell: the subapp handles it if it wants to (eventually using a DrupalKernel)

  [2011-12-09 20::53:26] Crell: I see.

  [2011-12-09 20::53:33] Stof: depending of what the subapp is meant to do

  [2011-12-09 20::53:44] Crell: So a block could be directly callable or not, depending on what class it inherits from.

  [2011-12-09 20::53:53] Stof: let's see someone does a subapp simply to add jQuery in all pages

  [2011-12-09 20::53:54] Crell: So a lightweight and heavyweight version.

  [2011-12-09 20::54:09] Stof: it does not need to match the node or to dispatch events

  [2011-12-09 20::54:21] » drak joined the chat room.

  [2011-12-09 20::56:56] Crell: OK, I need to get to dinner.

  [2011-12-09 20::57:20] drak: Hi Crell

  [2011-12-09 20::57:36] Crell: But... I think you just saved me about 6 months of work, and replaced it with 6 months of political maneuvering.