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

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 17:00:18 UTC