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.sire@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

Received on Tuesday, 27 January 2009 22:51:44 UTC