Re: Using W3C widgets in a web container: two implementations contrasted

On 17 Jan 2009, at 05:26, Marcos Caceres wrote:
>
>> In addition, both projects wanted to add additional functionality to
>> the API; this has included state coupling and shared states to enable
>> richer interaction between (a) widgets in the same user context and
>> (b) instances of the same widget from different users (i.e.
>> collaborative applications such as chat and voting).
>>
>> Note that though both were funded by the EC IST programme, Palette  
>> and
>> TenCompetence had not been collaborating prior to a recent event  
>> where
>> members of both were asked to provide papers, when we discovered we
>> had undertaken parallel efforts at solving the same problems with the
>> same specifications! Hopefully this gives others an opportunity to
>> learn from our different approaches.
>
> Any feedback you have from implementing the packaging spec would be
> particularly helpful at this point. WRT APIs, we are very open to  
> hearing
> what you have in mind. However, having looked at the link you sent  
> above,
> I'm wondering why you didn't rely on XMLHttpRequest for doing the  
> network
> requests?

Hi Marcos,

The engine/platform has to provide a means for a widget to access  
externally-offered web services without breaking the same origin  
policy of the browser. To do this both projects have implemented a  
server-side proxy that routes requests from the widget via the widget  
engine, so that widgets only make requests within the same domain from  
which they are served.

In the case of Wookie, the Widget object has a proxify(url) method  
that just returns a rewritten URL formatted for a server-side  
whitelisting proxy; the widget JS implementation can then invoke  
XMLHttpRequest (or use an AJAX library such as Prototype) - with the  
value of the "proxified" URL instead of using the original URL, which  
would most likely be blocked by the browser as a x-site scripting  
violation.

E.g. if the original URL was "http://www.elsewhere.com/service/" then  
the result of proxify("http://www.elsewhere.com/service")  might be "https://www.here.com/wookie/services/proxy?url=http%3A%2F%2Fwww.elsewhere.com%2Fservice%2F 
"

In the case of Palette, the project created wrappers methods in the  
Widget object for the various remote access methods (get, post,  
getJSON, put, delete) that rewrites the request to point via its proxy  
endpoint.

The net result is the same, but the question is which is the better  
approach in terms of API design? We designed an approach to give  
widget developers flexibility wrt libraries and tools for handling  
requests; Palette's design goal was for making development of widgets  
simpler.

S

Received on Saturday, 17 January 2009 20:03:03 UTC