Could you not 'emulate' this by using varnish/ESI technology to build the page on the caching webserver and output it gradually? (like have the header/footer as their own ESI pages or something?)
t On Sun, Nov 21, 2010 at 13:04, Diogo Santiago <[email protected]>wrote: > As i see they need to convert it to a mode that must implemnet a module > that needs an info from a framework device thas implementes the interface > from the google module... > > U can just do it by making the annoince script API. Just work it around... > If you are not sucefull ont this.. Dont regret in contact me ...Peace > > ---------------------------------- > Atensiosamente. > Diogo Santiago > > --- Em *sex, 19/11/10, Lukas Kahwe Smith <[email protected]>* escreveu: > > > De: Lukas Kahwe Smith <[email protected]> > Assunto: Re: [symfony-devs] Chunked Responses in Symfony 2 > Para: [email protected] > Data: Sexta-feira, 19 de Novembro de 2010, 19:06 > > > > On 19.11.2010, at 15:18, Jordi Boggiano wrote: > > > On Fri, Nov 19, 2010 at 8:12 PM, Lukas Kahwe Smith > > <[email protected]<http://br.mc538.mail.yahoo.com/mc/[email protected]>> > wrote: > >> now once you are inside a twig template you have stuff like blocks and > extends. so with twig it should be possible to travel upto the most outer > extend. we could also make it possible to "tag" blocks, f.e. "javascript", > "css", .. now in the most outer layout we can then have "yield" calls that > basically say if all blocks tagged with the given yield label have been > processed, then flush up to this point. > >> > >> so essentially twig could process blocks inside the templates in a > different order than like they are actually defined in order to more quickly > be able to push out content. the blocks would each "pull" in the content > that they need, thereby delaying expensive calls as long as possible. > > > > For frontend (and I mean *in the browser*) performance, what matters > > is that the head tag is output as soon as possible, and it must > > contain all stylesheets to make this worthwhile. The rest of the page > > is less critical because when head is received the browser will start > > fetching stylesheets and attached dependencies (images). > > right .. it might make sense to have a simple solution for just this use > case. i guess the chances are low that someone wants to implement some long > polling solution on top of sf2. > > > The main thing that made me drop the ball on this is that given the > > way Symfony2 handles requests, you need a fully populated response > > object at the moment for output to even begin. It is then passed to > > that core.response event/filter, which means the output could be > > modified there. > > Right, chunked response will probably make some magic impossible. but it > seems like an important enough use case to at least optionally support out > of the box. > > > The only solution I see, and I'm really not sure how feasible it is, > > is to have "streaming" request objects, that would just dispatch an > > event every time they're flushed (or yield), and that would dispatch > > core.response on the current output so it can be filtered. It would > > however mean that output filters would have to be able to handle html > > fragments and not a full page tree at once. It doesn't sound too > > impossible, but I haven't looked in detail at the current > > implementation. > > > right .. all filters would need to be aware of the output mode and they > should probably receive some context information in order to know at which > "step" of the response its being called. maybe filters for this streaming > response would actually be registered on the "step" in order to prevent too > much overhead being introduced by repeatedly triggering all filters. > > regards, > Lukas Kahwe Smith > [email protected]<http://br.mc538.mail.yahoo.com/mc/[email protected]> > > > > -- > If you want to report a vulnerability issue on symfony, please send it to > security at symfony-project.com > > You received this message because you are subscribed to the Google > Groups "symfony developers" group. > To post to this group, send email to > [email protected]<http://br.mc538.mail.yahoo.com/mc/[email protected]> > To unsubscribe from this group, send email to > [email protected]<http://br.mc538.mail.yahoo.com/mc/[email protected]> > For more options, visit this group at > http://groups.google.com/group/symfony-devs?hl=en > > > > > -- > If you want to report a vulnerability issue on symfony, please send it to > security at symfony-project.com > > You received this message because you are subscribed to the Google > Groups "symfony developers" group. > To post to this group, send email to [email protected] > To unsubscribe from this group, send email to > [email protected]<symfony-devs%[email protected]> > For more options, visit this group at > http://groups.google.com/group/symfony-devs?hl=en > -- If you want to report a vulnerability issue on symfony, please send it to security at symfony-project.com You received this message because you are subscribed to the Google Groups "symfony developers" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/symfony-devs?hl=en
