Since the specification only specifies the move and resize methods of
the window object, what you are saying is that if embedded in a
webpage we would just have to accept that these widgets are not
allowed to move or resize themselves? This seems a bit odd. If the
widget rendering system (ie, the parent webpage) could be alerted to
the widget's wanting to be moved/resized, some systems would do it for
them, some would not, but it would be nice to have the option. I
understand the logic here, but it does limit implementation a bit
(which would likely end up being supplemented by an 'extended' but
non-standard Javascript library).
I'll look into this. But I still don't think its much of a problem....
Flash has a function called "fscommand" which allows you to talk to
JavaScript in the browser. So, in theory, a flash movie can do this:
inside flash:
fscommand("growMe", ({width:100,height:100}));
inside HTML script:
function growMe(dimension){
$("flashmovie").style.width += dimension.width;
$("flashmovie").style.height += dimension.height;
}
Worst case, we can define something similar to 'fscommand' for
widgets. However, I don't feel strongly about this ATM.
>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.
--
Marcos Caceres
http://datadriven.com.au
