Data Pipelining Best Practices query

[Taylor Singletary <ts...@linkedin.com>]

Reposting to Shindig-Dev from the OpenSocial Application Development  
List:

Hi all,
I have some basic questions regrading best practices with using data
pipelining:
1) Is it possible to evaluate pipelining tags like HttpRequest and
PeopleRequest that are either dynamically inserted into the DOM via
Javascript, or within incoming responses from a HttpRequest or
makeRequest?
2) Error Handling/Retry: Sometimes the result of an HttpRequest or
PeopleRequest will result in error (for example when a server takes
too long to respond and the container terminates the request). Is the
most proper way to respond to these by evaluating the error condition
and retrying via makeRequest (and then pump the response from the
callback into the context DataSet?) Or alternately, depending on the
status of the first question, inserting another pipelining request
into the DOM and evaluating it?
2) What about scenarios where you only conditionally want to request
People resources? For instance, you might want to conditionally
request the owner friends based on whether you need a connection type
ahead search invoked by user action. In this case, is falling back to
makeRequest and the fetchPerson/People Javascript API best?
3) Any other best practices tips?
Thanks,
Taylor

  

Re: Data Pipelining Best Practices query

[Taylor Singletary <ts...@linkedin.com>]

Thanks for the help, Adam. Very useful. I guess I'll finally take a  
look at the OSAPI and determine its compatibility on our container.

Thanks!
Taylor

On Aug 5, 2009, at 9:00 AM, Adam Winer wrote:

> On Wed, Aug 5, 2009 at 8:01 AM, Taylor
> Singletary<ts...@linkedin.com> wrote:
>> Reposting to Shindig-Dev from the OpenSocial Application  
>> Development List:
>>
>> Hi all,
>> I have some basic questions regrading best practices with using data
>> pipelining:
>> 1) Is it possible to evaluate pipelining tags like HttpRequest and
>> PeopleRequest that are either dynamically inserted into the DOM via
>> Javascript, or within incoming responses from a HttpRequest or
>> makeRequest?
>
> No.  Use the osapi API, which has 1-1 syntax correspondence and is
> way, way, way easier to use than creating DOM elements.
>
>> 2) Error Handling/Retry: Sometimes the result of an HttpRequest or
>> PeopleRequest will result in error (for example when a server takes
>> too long to respond and the container terminates the request). Is the
>> most proper way to respond to these by evaluating the error condition
>> and retrying via makeRequest (and then pump the response from the
>> callback into the context DataSet?) Or alternately, depending on the
>> status of the first question, inserting another pipelining request
>> into the DOM and evaluating it?
>
> Again, use osapi.  In the spec group, we talked about exposing the
> original set of JSON request objects, making retry easier.
>
> For "server-taking-too-long-to-respond", I'm unsure we want to
> encourage gadget developers to write retry logic, though:  an
> overloaded server does not need clients retrying, it needs clients
> backing off.  In general, showing a good error message is probably
> better.
>
>> 2) What about scenarios where you only conditionally want to request
>> People resources? For instance, you might want to conditionally
>> request the owner friends based on whether you need a connection type
>> ahead search invoked by user action. In this case, is falling back to
>> makeRequest and the fetchPerson/People Javascript API best?
>
> No, use osapi.
>
>> 3) Any other best practices tips?
>
> Use osapi. ;)
>
> -- Adam
>
>> Thanks,
>> Taylor
>>
>>
>>

Re: Data Pipelining Best Practices query

[Adam Winer <aw...@google.com>]

On Wed, Aug 5, 2009 at 8:01 AM, Taylor
Singletary<ts...@linkedin.com> wrote:
> Reposting to Shindig-Dev from the OpenSocial Application Development List:
>
> Hi all,
> I have some basic questions regrading best practices with using data
> pipelining:
> 1) Is it possible to evaluate pipelining tags like HttpRequest and
> PeopleRequest that are either dynamically inserted into the DOM via
> Javascript, or within incoming responses from a HttpRequest or
> makeRequest?

No.  Use the osapi API, which has 1-1 syntax correspondence and is
way, way, way easier to use than creating DOM elements.

> 2) Error Handling/Retry: Sometimes the result of an HttpRequest or
> PeopleRequest will result in error (for example when a server takes
> too long to respond and the container terminates the request). Is the
> most proper way to respond to these by evaluating the error condition
> and retrying via makeRequest (and then pump the response from the
> callback into the context DataSet?) Or alternately, depending on the
> status of the first question, inserting another pipelining request
> into the DOM and evaluating it?

Again, use osapi.  In the spec group, we talked about exposing the
original set of JSON request objects, making retry easier.

For "server-taking-too-long-to-respond", I'm unsure we want to
encourage gadget developers to write retry logic, though:  an
overloaded server does not need clients retrying, it needs clients
backing off.  In general, showing a good error message is probably
better.

> 2) What about scenarios where you only conditionally want to request
> People resources? For instance, you might want to conditionally
> request the owner friends based on whether you need a connection type
> ahead search invoked by user action. In this case, is falling back to
> makeRequest and the fetchPerson/People Javascript API best?

No, use osapi.

> 3) Any other best practices tips?

Use osapi. ;)

-- Adam

> Thanks,
> Taylor
>
>
>