Re: Using W3C widgets in a web container: two implementations contrasted
Indeed; however as the difference is so small in practice, we thought it worthwhile to pursue a solution based on the W3C work, rather than use a proprietary solution. At the spec level, it only really requires one extra API method. S On 28 Jan 2009, at 13:30, Marcos Caceres wrote: Hi Scott, On Wed, Jan 28, 2009 at 9:51 AM, Scott Wilson scott.bradley.wil...@gmail.com wrote: 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 [1] http://www.w3.org/TR/widgets-land/#differences -- Marcos Caceres http://datadriven.com.au
Re: Using W3C widgets in a web container: two implementations contrasted
On Thu, Jan 29, 2009 at 4:55 PM, Scott Wilson scott.bradley.wil...@gmail.com wrote: Indeed; however as the difference is so small in practice, we thought it worthwhile to pursue a solution based on the W3C work, rather than use a proprietary solution. At the spec level, it only really requires one extra API method. Ok, that's really encouraging to hear. Although we haven't focused on the same problem space, it's great to hear that the specification was still applicable. Kind regards, Marcos -- Marcos Caceres http://datadriven.com.au
Re: Using W3C widgets in a web container: two implementations contrasted
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.
Re: Using W3C widgets in a web container: two implementations contrasted
Hi Scott, On Wed, Jan 28, 2009 at 9:51 AM, Scott Wilson scott.bradley.wil...@gmail.com 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 [1] http://www.w3.org/TR/widgets-land/#differences -- Marcos Caceres http://datadriven.com.au
Re: Using W3C widgets in a web container: two implementations contrasted
Hello Scott Marcos, First I am pleased to hear that you are interested in the proxifying mechanisms. When you say Marcos: This might not be too much of an issue so long as the author declares which domains they want to communicate with. That way, the widget engine can allow access to the desired domains without requiring a server-side proxy as an intermediary. As I understand it, your concern is to keep the native XMLHttpRequest object for communications and then not introduce any new proxyfing API inside the Widget API ? However, using the current XMLHttpRequest object in existing browsers, how would it be aware of the white list mechanism (the desired domains) ? 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 ? There is also another point I would have been interested to know if webapps is interested about. It's about what we called the State coupling between widgets. In the PALETTE Portal (myWiWall), it consists in the addition of 5 methods to the widget API that allows: 1/ widgets to notify and subscribe to events from other widgets 2/ widgets to define draggable data and to subscribe to drop events (this was build on top of 1/) We have implemented these mechanisms and it supports real world use cases (see for instance snapshots [1] and [2] which we discuss in [3]). Is inter-widgets communication something you are heading too in the widget APIs and Events specification ? If this is the case, we could provide you with a more detailed description of what we have done. I have also seen that the latest draft of widget APIs and Events (22 January 2009) introduces a showNotification and a WidgetModeChangeEvent interface, but as far as I understand, this can also be dealt with a more general inter-widgets communication API. Regards, Stéphane S. --- [1] http://tinyurl.com/palette-mywiwall-dnd-weather [2] http://tinyurl.com/palette-mywiwall-dnd-translate [3] Talk about widgets - http://groups.google.fr/group/talk-about-widgets
Re: Using W3C widgets in a web container: two implementations contrasted
Hi Stéphane, On Tue, Jan 27, 2009 at 2:20 PM, Stéphane S. stephane.s...@epfl.ch wrote: Hello Scott Marcos, First I am pleased to hear that you are interested in the proxifying mechanisms. When you say Marcos: This might not be too much of an issue so long as the author declares which domains they want to communicate with. That way, the widget engine can allow access to the desired domains without requiring a server-side proxy as an intermediary. As I understand it, your concern is to keep the native XMLHttpRequest object for communications and then not introduce any new proxyfing API inside the Widget API ? However, using the current XMLHttpRequest object in existing browsers, how would it be aware of the white list mechanism (the desired domains) ? I envisioned that this would be controlled by some (yet to be defined) security policy for a widget. In a sense, this means that the widget engine would block requests to domains the widget was not authorized to access. 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. There is also another point I would have been interested to know if webapps is interested about. It's about what we called the State coupling between widgets. In the PALETTE Portal (myWiWall), it consists in the addition of 5 methods to the widget API that allows: 1/ widgets to notify and subscribe to events from other widgets 2/ widgets to define draggable data and to subscribe to drop events (this was build on top of 1/) We have implemented these mechanisms and it supports real world use cases (see for instance snapshots [1] and [2] which we discuss in [3]). Is inter-widgets communication something you are heading too in the widget APIs and Events specification ? If this is the case, we could provide you with a more detailed description of what we have done. Cross widget communication is certainly within scope. Please see requirement 33 in the requirements document [4]. I have also seen that the latest draft of widget APIs and Events (22 January 2009) introduces a showNotification and a WidgetModeChangeEvent interface, but as far as I understand, this can also be dealt with a more general inter-widgets communication API. We would certainly like to hear more about this! Kind regards, Marcos --- [1] http://tinyurl.com/palette-mywiwall-dnd-weather [2] http://tinyurl.com/palette-mywiwall-dnd-translate [3] Talk about widgets - http://groups.google.fr/group/talk-about-widgets [4] http://dev.w3.org/2006/waf/widgets-reqs/#r33.- -- Marcos Caceres http://datadriven.com.au
Re: Using W3C widgets in a web container: two implementations contrasted
On Sat, Jan 17, 2009 at 8:02 PM, Scott Wilson scott.bradley.wil...@gmail.com wrote: 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. Ok, makes sense. 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. Also makes sense. 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. Ok, I guess the thing the working group needs to take away from this is how do we deal with widgets not having an origin. This might not be too much of an issue so long as the author declares which domains they want to communicate with. That way, the widget engine can allow access to the desired domains without requiring a server-side proxy as an intermediary. Given your implementation experience, if you have any suggestion on how you think we should proceed we would certainly like to hear them. Kind regards, Marcos -- Marcos Caceres http://datadriven.com.au
Re: Using W3C widgets in a web container: two implementations contrasted
Hi, Scott! On 1/14/09 7:55 PM, Scott Wilson scott.bradley.wil...@gmail.com wrote: All, Two EU-funded projects have implemented the draft W3C Widgets specifications, both the packaging and API parts. This is fantastic to hear. What is notable from these projects have been the adaptations used to enable widgets conforming to the draft to be used in a web environment rather than in a dedicated platform such as a browser, OS or device widget layer. We've documented and discussed the extensions and implementation approaches here: http://groups.google.com/group/talk-about-widgets/web/implementating-the-w3c-w idget-specification In brief, the Palette project has added W3C widgets functionality through developing the engine as part of an open-source portal web application, whereas the TenCompetence project developed a standalone open-source engine for adding widgets to multiple web applications, rather similar in approach to the Apache Shindig project for implementing Google OpenSocial. Interesting. 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? Both projects are focussed on networked learning solutions and research, for which Widgets provided an elegant solution to a number of issues in reaching learners and co-ordinating access to functionality. For more background on the projects themselves, see: http://www.tencompetence.org http://palette.ercim.org/ Thanks for this info. Kind regards, Marcos
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
Using W3C widgets in a web container: two implementations contrasted
All, Two EU-funded projects have implemented the draft W3C Widgets specifications, both the packaging and API parts. What is notable from these projects have been the adaptations used to enable widgets conforming to the draft to be used in a web environment rather than in a dedicated platform such as a browser, OS or device widget layer. We've documented and discussed the extensions and implementation approaches here: http://groups.google.com/group/talk-about-widgets/web/implementating-the-w3c-widget-specification In brief, the Palette project has added W3C widgets functionality through developing the engine as part of an open-source portal web application, whereas the TenCompetence project developed a standalone open-source engine for adding widgets to multiple web applications, rather similar in approach to the Apache Shindig project for implementing Google OpenSocial. 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. Both projects are focussed on networked learning solutions and research, for which Widgets provided an elegant solution to a number of issues in reaching learners and co-ordinating access to functionality. For more background on the projects themselves, see: http://www.tencompetence.org http://palette.ercim.org/ Cheers, Scott /-/-/-/-/-/ Scott Wilson Assistant Director, JISC CETIS University of Bolton scott.bradley.wil...@gmail.com http://www.cetis.ac.uk/members/scott
