On Friday, September 23, 2011 at 8:33 PM, Charles Pritchard wrote:
> I've some strong reservations about expanding the scheme into dns-land.
I''m still looking into this, but I don't know how we get around that. If you
have any suggestions, sure would like to hear them.
>
>
>
> On Sep 23, 2011, at 9:59 AM, Mark Baker <[email protected]
> (mailto:[email protected])> wrote:
>
> > On Fri, Sep 23, 2011 at 12:41 PM, Marcos Caceres <[email protected]
> > (mailto:[email protected])> wrote:
> > > > On Thu, Sep 22, 2011 at 7:16 PM, Marcos Caceres
> > > > <[email protected] (mailto:[email protected])> 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.
