W3C home > Mailing lists > Public > public-webapps@w3.org > January to March 2009

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

From: Scott Wilson <scott.bradley.wilson@gmail.com>
Date: Wed, 28 Jan 2009 09:51:51 +0000
Cc: Stéphane S. <stephane.sire@epfl.ch>, public-webapps@w3.org
Message-Id: <88BEE18C-5520-41FB-B00F-8D5836D3F611@gmail.com>
To: Marcos Caceres <marcosscaceres@gmail.com>

Hi Marcos,

A widget engine, in our use of the term, is a server-side web  
application that publishes widgets and implements the Widget API as a  
web service accessible via AJAX. As it stands all browsers will block  
any cross-domain Javascript requests, and this will apply in all cases  
where a Widget is making use of an external web API (e.g., a weather  
API, or external RSS feed). The only other options are:

(1) always use JSONP calls instead of regular AJAX - but this requires  
changes at the service endpoint to support JSONP, which isn't really  
the widget ethos, which is about exposing web services in new ways  
without redesigning the services themselves
(2) constrain widgets to only invoke web services from within the same  
domain that hosts the widget - but this is extremely limiting, and  
couples the widget engine host to the web API host.
(3) have widgets invoke external requests via a server-side proxy  
offered in the same domain as the widget engine that is serving the  
widget

If the W3 work on access policy - for allowing read-only AJAX requests  
- gets built into browsers, then the requirement for server-side  
proxies for web widgets may be less in the future, as most widgets  
only make GET requests to external web services.

Note that Google also implements a server-side proxy for Gadgets to  
access external content, with the method "_IG_FetchContent(url,  
callbackFunc)", which is similar to the Palette approach.

Scott

On 27 Jan 2009, at 22:51, Marcos Caceres wrote:
>
>
>> Our concern in our implementations was to run in existing
>> browsers, hence the proxy solution... But maybe I misunderstand  
>> what you
>> call the "widget engine" in your sentence ?
>
> I was envisioning that a widget engine would leverage browser
> technology and would have the appropriate modifications made to allow
> the functionality required by the specification. Whether it is
> possible to do this is an implementation detail, but what is in the
> spec must certainly be able to happen in reality. I haven't built a
> widget engine, but I assume that it must be possible to modify a
> widget engine to only access a predefined set of domains without
> requiring a server-side proxy.
Received on Wednesday, 28 January 2009 09:52:35 GMT

This archive was generated by hypermail 2.3.1 : Tuesday, 26 March 2013 18:49:29 GMT