- From: Marcos Caceres <m.caceres@qut.edu.au>
- Date: Sat, 24 Feb 2007 20:25:07 +1000
- To: "Stephen Paul Weber" <singpolyma@gmail.com>
- Cc: arveb@opera.com, public-appformats@w3.org
> 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
Received on Saturday, 24 February 2007 10:25:16 UTC