shindig-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "jiraposter@reviews.apache.org (Commented) (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (SHINDIG-1669) Navigating to URLs in the common container has no indication of success or failure
Date Fri, 09 Dec 2011 14:26:41 GMT

    [ https://issues.apache.org/jira/browse/SHINDIG-1669?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13166202#comment-13166202
] 

jiraposter@reviews.apache.org commented on SHINDIG-1669:
--------------------------------------------------------


-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/3037/#review3779
-----------------------------------------------------------

Ship it!


LGTM

This is an interesting capability -- its too bad we couldn't find a way to get it done without
two requests though.

I did actually have one other thought about an alternative that could work (but again has
its own share of drawbacks -- many of which are the same as the head approach) but thought
I'd share anyway in case it spurs some thoughts from others too.  I was thinking there might
be a way to add another proxy to shindig for cases like this -- maybe something like IframeProxyServlet
-- so the iframe src would point to shindig-server/iframeProxy?url=http://example.com/theIframeContent.html
-- and then on the shindig side it could fetch the content, add a script include for the shindig
RPC library and then a script block that would fire a message to the parent container as soon
as it's processed.  On the parent page you could listen for the RPC call and when fired you'd
know the iframe loaded.  You could probably even do the same thing for the failure case on
the shindig side -- you return a page with a friendly error message saying that the content
failed to load and fire the RPC to the parent page with a message letting it know that the
iframe failed -- and you could even include any details you needed to as to exactly what failed.
 

Again -- just throwing out some thoughts here -- there would be plenty of issues with this
approach too (besides being much more work) like the iframe domain would be that of shindig
instead of the real host, relative links in documents probably wouldn't work unless they were
rewritten (which I guess shindig already knows how to do) etc -- but thought it was still
worth sharing in case anyone else was interested.

- Jesse


On 2011-12-08 17:58:33, Ryan Baxter wrote:
bq.  
bq.  -----------------------------------------------------------
bq.  This is an automatically generated e-mail. To reply, visit:
bq.  https://reviews.apache.org/r/3037/
bq.  -----------------------------------------------------------
bq.  
bq.  (Updated 2011-12-08 17:58:33)
bq.  
bq.  
bq.  Review request for shindig, Dan Dumont and Stanton Sievers.
bq.  
bq.  
bq.  Summary
bq.  -------
bq.  
bq.  When you call commoncontainer.navigateUrl if the URL cannot be reached the caller has
no way of knowing if the URL was navigated successfully or not. To solve this we make a head
request to the URL we are navigating to and add a callback to the API. 
bq.  
bq.  It is important to note that we will not be caching the response of the head request.
While this could possibly give us better performance we have no way of guaranteeing the server
will still be up next time and everything may fail. This is different from the gadget case
where we have the gadget XML cached on the server.
bq.  
bq.  
bq.  This addresses bug SHINDIG-1669.
bq.      https://issues.apache.org/jira/browse/SHINDIG-1669
bq.  
bq.  
bq.  Diffs
bq.  -----
bq.  
bq.    http://svn.apache.org/repos/asf/shindig/trunk/content/samplecontainer/examples/embeddedexperiences/PhotoList.xml
1211913 
bq.    http://svn.apache.org/repos/asf/shindig/trunk/features/src/main/javascript/features/container.util/util.js
1211913 
bq.    http://svn.apache.org/repos/asf/shindig/trunk/features/src/main/javascript/features/container/container.js
1211913 
bq.    http://svn.apache.org/repos/asf/shindig/trunk/features/src/main/javascript/features/embeddedexperiences/embedded_experiences_container.js
1211913 
bq.    http://svn.apache.org/repos/asf/shindig/trunk/features/src/main/javascript/features/open-views/viewenhancements-container.js
1211913 
bq.    http://svn.apache.org/repos/asf/shindig/trunk/features/src/test/javascript/features/container.url/container_url_test.js
1211913 
bq.  
bq.  Diff: https://reviews.apache.org/r/3037/diff
bq.  
bq.  
bq.  Testing
bq.  -------
bq.  
bq.  Tested in container as well as updating unit tests.
bq.  
bq.  
bq.  Thanks,
bq.  
bq.  Ryan
bq.  
bq.


                
> Navigating to URLs in the common container has no indication of success or failure
> ----------------------------------------------------------------------------------
>
>                 Key: SHINDIG-1669
>                 URL: https://issues.apache.org/jira/browse/SHINDIG-1669
>             Project: Shindig
>          Issue Type: Improvement
>    Affects Versions: 3.0.0
>            Reporter: Ryan Baxter
>   Original Estimate: 48h
>  Remaining Estimate: 48h
>
> When you call commoncontainer.navigateUrl if the URL cannot be reached the caller has
no way of knowing if the URL was navigated successfully or not.  To solve this we make a head
request to the URL we are navigating to and add a callback to the API.
> It is important to note that we will not be caching the response of the head request.
 While this could possibly give us better performance we have no way of guaranteeing the server
will still be up next time and everything may fail.  This is different from the gadget case
where we have the gadget XML cached on the server.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

       

Mime
View raw message