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

On Monday, September 26, 2011 at 4:31 PM, Robin Berjon wrote:

> On Sep 23, 2011, at 18:26 , Mark Baker 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
>  
> Well, the advantage of a scheme is that it's solidly in the realm of the implementation to decide how to handle it. We've actually been bouncing ideas like the above around for a while (albeit with things like .app rather than .localhost) and it's a bit scary. It means that in some cases you're doing DNS resolution differently than the way in which you normally do it (which might just be relying on the system).  
This is the problem I've run into at the moment. I can't seem to get around it:  

* Either add sub domains to localhost in the "hosts" file
* use virtual hosts in Apache
* I don't think either gives me dynamic dns capabilities (for when I start new widgets, I create a new subdomain… and no idea how to do it on Android… there is no API, AFACT).  

All the java HTTP servers I have been looking at naturally assume a TCP/IP socket. Replacing that with a, um, kinda native socket, is not really working for me.  

Anyway, I don't think there is a way around this… I think the browser will always do it's own network request over TCP/IP and that will need to be intercepted through a socket (unless widget:// is supported natively).  

> It means surprising results if you add c13c6f30-ce25-11e0-9572-0800200c9a66.app to your hosts file and see it do one thing in the browser and another in a widget.

Yeah :( Or trying to stop a widget from getting into the resources of another widget (referrer check to stop one widget getting into another widget seems somewhat fragile)… and the battery sucking while(true){ } for the thread that listens is not too nice either.  

> There are however many useful benefits in tying a packaged web application (using whatever packaging) to an origin, not the least of which is same-origin policy and overall just being a regular web app (that may happen to have been loaded differently).
I still don't think it's that bad to do http://c13c6f30.whatever  

Mark, what is the issue with using sub.localhost? (i.e., why do you discourage using .localhost)?  
>  
> Overall I'd rather wait for the outcome from the Offline Web Apps workshop to have a definitive opinion on which approach is best. Be sure to be there! http://www.w3.org/2011/web-apps-ws/

This presupposes that someone there will have an opinion :) I was, at least, going to write my paper around this… but I imagine it will go a lot like… "um, I tried doing this… it kinda didn't work, um… yeah… so, hhmm… would be very useful, however" :).

Received on Monday, 26 September 2011 14:44:11 UTC