Re: [WARP] Last Call comments (1)

On Sep 8, 2009, at 11:00 , Marcin Hanclik wrote:
> As stated in my original email, one of the targets is that <access>  
> is not an obstacle for DAP.

The design was based on:

  - not restricting DAP's ability to define a security policy
  - enabling boolean access to URIs
  - having pattern matching that covers most cases
  - making sure that web content that works outside of a widget can  
work inside a widget

> It is currently undefined how the related access control will be  
> done and we would probably want to avoid the situation that <access>  
> is deprecated once DAP is ready with their model.

Quite the contrary. If all goes well DAP's security policy will be  
available within a couple years, and after that we'll need another  
year before it ships as presumably it'll have some degree of  
complexity. That's all fine but the problem that we have today is that  
people are shipping implementations with support for something a lot  
like <access> but that are not compatible. Just off the top of my head  
I know that Opera has their own stuff (which was the original  
proposal), BONDI has <network-access> which is different, JIL has  
something of their own with different default rules, and Microsoft has  
a widget engine using <access> from the December 2008 PC draft.

What WARP does is that it provides the strictly minimal solution that  
will make interoperability possible before DAP finishes its work,  
while adhering to its fundamental design principles. If it gets  
obsoleted, superseded, set on fire in public displays of wrath, or  
trampled by a horde of arctic hippopotami on MDMA then great. The  
primary goal is to gain 3 years of interoperability which we need to  
have. A complementary goal is that since we want content created  
conforming to WARP today to be valid forever is that the policies that  
WARP enables should be expressible using whatever DAP comes up with,  
so that <access> can be defined as simply a syntactical shortcut to DAP.

In other words it is future-proof *because* it is simple. It's  
extensible (if we need to, which I don't think we should) because it's  
XML (and because its processing model is intended for that).

-- 
Robin Berjon - http://berjon.com/

Received on Thursday, 17 September 2009 14:41:10 UTC