Simple approach for <access>

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  
<access>.

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 on the same);
  - a widget like the above, but the service uses multiple subdomains  
to distribute its load (e.g. web42.example.org,  
web2017.images.example.org...);
  - a widget that has to access pretty much any HTTP resource (e.g. an  
RSS reader).

There are possibly cases in which we might want to allow a widget to  
access ports 8042 through to 8077, and 99, 1010, 2017, on some  
combinations of gopher and sftp for all of dahut.fr, dahut.org, and  
dahut.com but I don't think that those fall in the 80%.

So here goes (not in spec-ese):

"""
The <access> element is used to restrict a widget's access to a  
limited set of network resources. In the absence of an <access>  
element, all access to network resources is forbidden.

The <access> element has a single @href attribute the content of which  
is an IRI-like string. The access opening that is specified by that  
string is defined as follows:

  - the scheme component MUST be present, and access is granted only  
for that scheme; and
  - the host component MUST be present. If it begins with "*." then  
the host that follows the "*." is granted access to, as well as all of  
its lower-level domains; otherwise access is only granted for that  
domain; and
  - if the port component is absent, it is considered to be specified  
to be the default for the provided scheme. Access is granted only to  
that port; and
  - if the path and query string component is present, then access is  
granted for any path and query string that starts with the specified  
string. It is treated as an opaque string, no attempt must be made to  
map to potential directories on the remote server; and
  - if a fragment component is specified, it must be ignored.
"""

I think that the above, once tightened up for proper spec wording,  
gives us our basic three use cases (given that one can easily specify  
a handful of <access> elements) at a minimal cost. Derived on the  
above, once we see which paths are trodden and what people complain  
about (and we can rely on complaints to reach us) we can extend the  
element to provide it with much more granular matching (simply by  
giving it children or other attributes that override href). The point  
here is not to make it perfect, but to make it good enough to ship.

Comments?

-- 
Robin Berjon - http://berjon.com/
     Feel like hiring me? Go to http://robineko.com/

Received on Thursday, 26 March 2009 16:04:41 UTC