launchpad-dev team mailing list archive

[Aaron Bentley <aaron@xxxxxxxxxxxxx>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 12-02-21 05:05 PM, Robert Collins wrote:
> Lists of content such as lp.net/bzr/2.0 have a bunch of different
> data to assemble, *and* we want server rendering for Google. That
> means we need a View class, and we will have the data locally so
> shoving it into the LP JSONCache is a simple and effective means of
> handing it off to the client. That said, its also a waste: we have
> already rendered the content at that point (because we want to show
> it to Google) so we may as well just hand over the rendered HTML
> (or browser-sniff and render exclusively on the client for 
> non-search-bots). Transmitting the same data twice is a waste
> though; I am strongly in favour of rendering directly on the client
> all the time. It is desirable to do so because of things like the
> cog on the bug listings view that lets additional data not rendered
> by default be added to the view - we need all the data which the
> initial server rendered output wouldn't necessarily include (unless
> we change how we tackle it and hide content using css classes
> rather than template output - one constant render, client side
> visibility choices).

I'm in favour of dropping server-side rendering for sessions when
client-side rendering is supported.  Is that what you mean?

And in fact, it looks like hiding content would have been a better
option for bug listings, because that can be done more smoothly in
Firefox.

> we can always fall back to the JSONCache, for all that it does
> (roughly) double the page size.

But it only doubles the page size when we use server-side rendering.
Clients can get the JSONCache via ++model++ urls.

Aaron
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAk9EIwwACgkQ0F+nu1YWqI2GgACeNLGYN4RcJKXBF4qE6esAOU4p
LDcAmwZ+XSSIU8WS9SydGo6x/T3aiFv5
=7Yi7
-----END PGP SIGNATURE-----