launchpad-dev team mailing list archive

[Benji York <benji.york@xxxxxxxxxxxxx>]

On Thu, Feb 23, 2012 at 7:54 PM, Robert Collins
<robertc@xxxxxxxxxxxxxxxxx> wrote:
> On Wed, Feb 22, 2012 at 5:25 PM, Benji York <benji.york@xxxxxxxxxxxxx> wrote:
>> There is provision for non #! URLs.  See section 3.
>
> So, I think what you mean is:
>  - there is no need to render server side on the /normal/ URL for a
> page just for search engines, as the mapping logic used for #! will
> let you describe (to search engines) where to go to get a flat
> rendered version of the page.

Right.

>  - this would allow us to not browser sniff

And we wouldn't have the other irritations that come with browser
sniffing like having to make sure index bots don't get cached pages that
include client-side rendered results.

>  - but we would still need to have a server side render code-path,
> which would have to do very similar stuff under such conditions to the
> client side render

The idea is that the server-side rendering can be much simpler than what
we do for the client side.  If it really is just for search engine
consumption, then we don't need the normal page furniture like
navigation or even any user-actionable accoutrements.  In fact, we would
be giving much more focused input to the search engine since it wouldn't
have the option of being confused by those things.

Here's a science fiction story:  All the data used to render a page is
gathered up on the server and then serialized to JSON and sent to the
browser where it is rendered.  That generated page has one of these
pointers to the search-engine-friendly version which when requested does
the same data gathering but that data is just rendered to straight,
unstyled HTML that the bot consumes.  If the generated data is itself
cached in key/value store (since all of these clients are anonymous)
then we only gather it once.

I think our current JSONCache/lazr.restful infrastructure would be a
good match for the above story.

> If so, I think its largely swings and roundabouts, we can abstract it
> out fairly neatly either way, I think.

Thank goodness I found an online idiom dictionary that cut the mustard.
-- 
Benji York