|
Valid XHTML v1.0
Author Profile
Top Authors
| Author | # |
|---|---|
![]() |
185 |
![]() |
149 |
Anonymous User
![]() |
49 |
Kimberly Hieber
![]() |
27 |
![]() |
25 |
![]() |
20 |
Note: some conversations may be proxied or secured, thereby causing # differences
Subscribe
No Conversations ... start one
No Conversations ... start one
Tags
Popular
|
|
Potentional Pain Point in Gadget Management
belongs to OpenSocial Gadgets ![]() by Jonathan Bell on 2008-10-03 09:46 PM read 124 times |
I wanted to point out a potential pain point in shindig management. This resolves around the rpc and pubsub features. These features allow gadgets to communicate and broadcast events to each other
The way these features are able to work through the browser domain security with iframes is via a relay URL. The way this works is the following:
Suppose you have a hub on domain kalivo.com. Now lets say it has a gadget loaded on its page via an iframe that is pointed to gadget.com. Now if the gadget on gadget.com needed to communicated to kalivo.com, due to browser cross-site scripting security (XSS), direct communication would be prevented. The way shindig gets around this is by providing a hidden iframe within the gadget.com iframe pointing to a well known "relay URL". This relay URLis hosted on kalivo.com and thus is on the same domain as the hub, therefore, it can parse its request parameters and invoke the communication to the hub.
Note, for HTML 5 supported browsers (FF3, IE8, etc), the gadget will instead call window.postMessage directly to the hub, however it still passes along the relay URL to the call to ensure the outer frame is the expected hub and not some other domain.
Therefore, in order to work in either case, the relay url must point to the hub, and must be known by gadget.com when it serves out the gadget. The way shindig organizes this is through the notion of containers. Containers are defined in specially named container.js files. Shindig sets up configuration for all sorts of properties, but most importantly the relay URL. These js files are loaded from the file system, however they must be referenced from within shindig server through the gadgets.properties file.
This presents a pain point because every time we add a hub, we must update the gadgets.properties file, rebuild the war (its stored within a jar file in WEB-INF/lib), and finally restart tomcat.
I know there was a lot of pain points with the referreral URL in the storage service because of a similar issue. Therefore, I think we should customize shindig to monitor /usr/local/gadget/container directory and dynamically add gadgets based on file changes.
1 Reply
|
Log In to Reply |
Log In to Copy |
Tell a Friend
|
Trackback URL: http://www.kalivo.com/trackback/1751-potentional-pain-point-in-gadget-management
|
|
re: Potentional Pain Point in Gadget Management
by Brittain on 2008-10-08 03:28 PM read 23 times |
In the widget architecture review, one of the limitations of the nGenera Widget Framework is that developers need to add the proxy support. This sounds very similar (basically a best practice for cross communication). How would you contrast these two ?
Log In to Reply |
Log In to Copy |
Tell a Friend
|
Trackback URL: http://www.kalivo.com/trackback/1763-re-potentional-pain-point-in-gadget-management
