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

Hi Scott,
On Wed, Jan 28, 2009 at 9:51 AM, Scott Wilson
<> wrote:
> 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.

Ok, I see where you are coming from now. Our definition of widget is
different. Please see the Differences from Web Widgets section in the
Widgets Landscape document [1]. Our intention is to allow the
interactions you describe to occur on the client side without
requiring assistance from the server side.

Kind regards,


Marcos Caceres

Received on Wednesday, 28 January 2009 13:31:19 UTC