On 19 Apr 2009, at 16:24, Robin Berjon wrote:
On Apr 16, 2009, at 17:23 , Thomas Roessler wrote:
1. How is the information in this access element going to be used
at installation time or distribution time? I'd like to see some
spec text that explains this.
My understanding is that this is
Hi Thomas,
On Apr 16, 2009, at 17:23 , Thomas Roessler wrote:
1. How is the information in this access element going to be used at
installation time or distribution time? I'd like to see some spec
text that explains this.
My understanding is that this is like the feature element and others
Hi Scott,
On Apr 16, 2009, at 18:18 , Scott Wilson wrote:
So far we haven't come across a widget thats needed more than - at
most - access to a few services, all coded as a single URL or single
domain. The only exception to the rule are RSS widgets, but these
are right at the other end of
In our implementation we plan to use the information to
provide the information needed for our whitelist proxy server; however
it would be a hint to the administrator to confirm adding the
whitelist rules requested by the widget rather than be an automated
addition to the whitelist.
So f
Robin wrote:
The element is used to restrict a widget's access to a
limited set of network resources. In the absence of an
element, all access to network resources is forbidden.
The element has a single @href attribute the content of which
is an IRI-like string. The access opening that is sp
t address, I
> would like to propose a similarly simple approach for .
>
> I think there are three primary use cases which we genuinely need to
> address:
>
> - a widget that access a single source, or a small set of sources (e.g.
> three servers for a mashup, or http and https o
Hi,
in the same spirit of the resolution that we made with L10N based on
the principle that we define something simple now and add more complex
stuff once developers have described real-world issues that we don't
address, I would like to propose a similarly simple approach for
