I've some strong reservations about expanding the scheme into dns-land.
On Sep 23, 2011, at 9:59 AM, Mark Baker <dist...@acm.org> wrote: > On Fri, Sep 23, 2011 at 12:41 PM, Marcos Caceres <w...@marcosc.com> wrote: >>> On Thu, Sep 22, 2011 at 7:16 PM, Marcos Caceres >>> <marcosscace...@gmail.com (mailto:marcosscace...@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. >