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" :).
