- From: Marcos Caceres <w3c@marcosc.com>
- Date: Fri, 28 Mar 2014 16:14:21 -0400
- To: uri@w3.org
On November 1, 2013 at 7:12:08 PM, John Cowan (cowan@mercury.ccil.org) wrote: > Mark Baker scripsit: > > > Marcos - I'm pretty sure we had this, or a very similar conversation > > back in the widget: or blob:(IIRC) scheme proposals. My position is > > that if it looks like http and works like http, that you should go out > > of your way to make it http (for all those "already deployed" reasons). > > There are two ways to do that. The user could be required to run an HTTP > server, which is known to be problematic, especially as there may be and > typically are multiple apps on the platform, which would have to ensure > that their uses of the server cooperate properly without collision. > By contrast, app: requires only a shared static file mapping UUIDs > to installed pathnames (though other implementations are possible, > of course). > > In the alternative, the user agent would be required to detect this as a > special case of the http: scheme in which a server is not to be contacted. > The difficulty there is that browsers are not the only relevant > kind of HTTP user agents, and *all* of them would need to be updated. > It's obvious to a downlevel user agent that it can't handle an app: URI; > it is not obvious that it can't handle an http: URI with a magical format. I'd like to close off this as it's the last remaining thing before we move the app: URL thing to LC. There are already 2 implementations and this is the last remaining bug in our tracker [1]. If it's not possible (or there is no consensus) to register the scheme, that is ok. Just want to know so I can close the bug in our tracker and have a record that an attempt to register app:// with IANA took place. [1] https://github.com/sysapps/app-uri/issues/24
Received on Friday, 28 March 2014 20:14:51 UTC