Re: Widgets 1.0

> Worst case, we can define something similar to 'fscommand' for
> widgets. However, I don't feel strongly about this ATM.

On more research, I've found that one can set window.resizeTo within a
script to an alternate function, so this could be made to work :)

> > >The bigger problem, if you're looking to embed these widgets in web pages
> > >is the security model of widgets, that allow for cross-domain
> > >XMLHttpRequest.
> >
> > This is indeed a problem.  It can, again, be overcome if widget
> > designers wishing their widget to work on and offline were to use some
> > other method (such as an optional proxy URL, ala Netvibes), but it
> > would be nice if this were somehow supported in the actual
> > specification.  Perhaps some sort of note could be made that there
> > SHOULD (if rendering in a webpage) be a variable in the JavaScript
> > (defined by the rendering system, ie, parent page) that contains a URL
> > to a proxy script (ie, http://example.com/proxy/?url=) and that if
> > this is present the widget code SHOULD access using this proxy.  If
> > using a desktop rendering system (ala Google Desktop) there SHOULD NOT
> > be such a variable.  If there is no such variable the widget code
> > SHOULD access resources directly.
>
> Sorry, this solution sounds a bit hackish to me. There are better ways
> to do off-line persistent storage. I also don't see how it addresses
> the XMLHttpRequest security issues Arve mentioned.
>
> Arve, I guess in regards to XMLHttpRequest security issue, the browser
> security model still applies.

:)  I didn't expect this suggestion to make it into anything W3C
related -- since it directly works to get around the security model.
It is something many sites are doing with webtop-style widgets though
:)

-- 
- Stephen Paul Weber <http://webos.singpolyma.net/>

Received on Sunday, 25 February 2007 19:54:42 UTC