W3C home > Mailing lists > Public > public-webapps@w3.org > April to June 2008

Re: [Widgets] Requirements LC

From: timeless <timeless@gmail.com>
Date: Fri, 20 Jun 2008 13:25:04 +0300
Message-ID: <26b395e60806200325u7d8e28bdt90085fff8f9557f0@mail.gmail.com>
To: "Arve Bersvendsen" <arveb@opera.com>
Cc: "Marcos Caceres" <marcosscaceres@gmail.com>, "public-webapps@w3.org" <public-webapps@w3.org>

On Fri, Jun 20, 2008 at 11:08 AM, Arve Bersvendsen <arveb@opera.com> wrote:
> The security policy proposed by Opera (and mostly implemented already)
> allows you to XHR any content stored within the package archive itself, just
> as it would allow you to include the contents of a package through <script
> src>, <img src> et al.

I guess I've failed to explain myself. (Please keep in mind that this
is a comment on the meta requirements spec. I haven't had time to
review much else, although I do want to.)

As long as the code actively uses XHR (or something else) to retrieve
data, I have no objection.

What I don't want is something where a property (of the settings
object!) is automatically resolved to the result of its pointer

If a property "icon" has value "http://example.org/favicon.ico", then
i would want retrieval of "icon" to yield
"http://example.org/favicon.ico" and not the _data_ that is at the
location <http://example.org/favicon.ico>.

I'm perfectly fine with the widget then using an XHR or whatever to
retrieve the data for the referenced location. I just don't want a
property lookup to resolve an indirection.

>  This happens through treating a widget: protocol
> URI where the identifier-portion matches the instance ID of the widget as
> being same-origin.  Thus, allowing XHR is an (intended) side-effect, so you
> can read other content from the widget (configuration data stored in an XML
> file or template snippets used throughout the application, for instance),
> and I don't think a specification will need to mention or reference XHR
> specifically, except perhaps informatively.

that's fine.
Received on Friday, 20 June 2008 10:25:45 UTC

This archive was generated by hypermail 2.3.1 : Friday, 27 October 2017 07:26:10 UTC