Re: [widgets] Killing file:// of evil (widget URI ready for pub)

I've some strong reservations about expanding the scheme into dns-land.





On Sep 23, 2011, at 9:59 AM, Mark Baker <distobj@acm.org> wrote:

> On Fri, Sep 23, 2011 at 12:41 PM, Marcos Caceres <w3c@marcosc.com> wrote:
>>> On Thu, Sep 22, 2011 at 7:16 PM, Marcos Caceres
>>> <marcosscaceres@gmail.com (mailto:marcosscaceres@gmail.com)> wrote:
>>> Well, this is progress, but it seems the only difference now between
>>> widget: and http: is the authority. And if that's the case, then
>>> instead of (from your example);
>>> 
>>> widget://c13c6f30-ce25-11e0-9572-0800200c9a66/index.html
>>> 
>>> why not go with this?
>>> 
>>> http://c13c6f30-ce25-11e0-9572-0800200c9a66.localhost/index.html
>> That might totally work:) The spec just needs to sandbox the request so apps don't request resources from each other (i.e., I just hope it's not hard to implement a kind of restricted-local-http server that widget:// tries to be… hopefully you get what I mean here: requests/response is instance specific, except where this could be used with postMessage… Also, I was worried about muddying-up the two "protocols", even if they are both http.
>> 
>> Another minor nit is that some runtimes already implement widget:// … but then again, they also implement http, so it might all be ok. Might have a crack at trying to implement this on Android.
> 
> That's great to hear, Marcos! I'll look for it in the market 8-)
> 
> FWIW - I should have mentioned this before - I wouldn't recommend
> requiring the use of ".localhost", just mention it as one option that
> implementers might consider.  For devices with their own IPs or DNS
> names, they should also have the option for using a more traditional
> authority;
> 
> http://<device-name-or-ip>/widget-instance/c13c6f30-ce25-11e0-9572-0800200c9a66/index.html
> 
> And obviously, in those cases, whether access is opened up to those
> widgets from outside the device is up to the implementers, carriers
> (where relevant), or (where I hope we get to eventually) user-defined
> access control policies.  But it does create some interesting
> possibilities!
> 
> Mark.
>

Received on Friday, 23 September 2011 18:34:18 UTC