0.9 Proxied Content for profile view

[davew]

Part of 0.9 includes Proxied Content. It's my understanding that we
can use Proxied Content (part of data pipelining) for the profile
view, without having to use Templates. Is that true on Orkut?

i.e.:
http://opensocial-resources.googlecode.com/svn/spec/draft/OpenSocial-Data-Pipelining.xml#rfc.section.10

<Content href="http://example.com/canvas" xmlns:os="http://
ns.opensocial.org/2008/markup">
<os:PeopleRequest key="vf" userId="@viewer" groupId="@friends"/>
</Content>

But I can't find any information on the invalidation of the proxy
cache. Is there an example that works in the Orkut sandbox? I
presume there's a REST or RPC call we can make to do the invalidation
so that the container only pulls the data when it actually needs
updating.

Then my understanding is we'll be able to do things like:

[1] Define a proxied content path to App Engine app
[2] When the proxied content is invalidated or the cache is out of
date the container will call our servers (App Engine) with the piped
data that we need about users (user names for a poke history)
[3] We can generate html for the profile view using the piped data and
return it as html. (Basically a pull model equivalent of setFBML on
facebook).
[4] The container will sanitize the html and update the profile view.

It would be great to see an example of this, and a confirmation that
this will be available to use instead of Templates. I see a lot of
talk about Templates on here, but nothing about Proxied Content, which
surprises me a little, because Proxied Content is closer to doing
things like setFBML on facebook - it's just a pull model instead of
the facebook push model to update the view.

Thanks!

Dave

[Apurv Gupta]

Hi Dave,

Proxied rendering will be available, but there are caveats. Let me try and explain while keeping confidential stuff, well, confidential.

We are trying to put apps on a more prominent place on the profile page. Part of that will involve moving away from the iframe and inlining the content.
Along with that, we need strong latency guarantees, otherwise the user will experience a hole above the fold. [Give how slow our apps are].

For the same reason, we discourage and will not support os:HttpRequest in the profile view.

Coming back to proxied rendering, it will work only when the results are in the cache. If there is a cache miss, we'll start a refresh, but not wait for the pull to complete. So you'll probably get only 50% of possible views, and you have can't use viewer in the request [or else it won't be cached].

AppEngine may be fast enough, but we don't control that.

For the same reasons, we aren't providing controls for adjusting the height of the profile view - since it will go away in a few months.

For now, you can go ahead and use proxied rendering, keeping in mind that it may not work as well in a few months.

Thanks,

-apurv

[davew]

Thanks Apurv for the explanation. It sounds like the most supported
way going forward (and safest) will be to use Templates that parse
data directly from the container's App Data. So I'll just stick with
that way of doing things.

Thanks!

Dave

On Apr 7, 6:48 am, Apurv Gupta <apurv.gu...@gmail.com> wrote:
> Hi Dave,
> Proxied rendering will be available, but there are caveats. Let me try and
> explain while keeping confidential stuff, well, confidential.
>
> We are trying to put apps on a more prominent place on the profile page.
> Part of that will involve moving away from the iframe and inlining the
> content.
> Along with that, we need strong latency guarantees, otherwise the user will
> experience a hole above the fold. [Give how slow our apps are].
> For the same reason, we discourage and will not support os:HttpRequest in
> the profile view.
>
> Coming back to proxied rendering, it will work only when the results are in
> the cache. If there is a cache miss, we'll start a refresh, but not wait for
> the pull to complete. So you'll probably get only 50% of possible views, and
> you have can't use viewer in the request [or else it won't be cached].
> AppEngine may be fast enough, but we don't control that.
>
> For the same reasons, we aren't providing controls for adjusting the height
> of the profile view - since it will go away in a few months.
>
> For now, you can go ahead and use proxied rendering, keeping in mind that it
> may not work as well in a few months.
>
> Thanks,
> -apurv
>

> On Sun, Apr 5, 2009 at 5:16 AM, davew <dave.westw...@gmail.com> wrote:
>
> > Part of 0.9 includes Proxied Content.  It's my understanding that we
> > can use Proxied Content (part of data pipelining) for the profile
> > view, without having to use Templates.  Is that true on Orkut?
>
> > i.e.:
>

> >http://opensocial-resources.googlecode.com/svn/spec/draft/OpenSocial-...