CFC, app: URI scheme

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
6 messages Options
Reply | Threaded
Open this post in threaded view
|

CFC, app: URI scheme

Marcos Caceres-4
The SysApps WG would appreciate if members of this list could review the app: URI scheme:

http://www.w3.org/2012/sysapps/app-uri/

A implementation of this uri scheme is used in FireFox OS.

If this group feels the scheme is ok, we would like to move towards a preliminary registration with IANA.

Any thoughts or comments would be greatly appreciated! Please file bugs in Github, or please send us an email at [hidden email].

Kind regards,
Marcos


--
Marcos Caceres



Reply | Threaded
Open this post in threaded view
|

Re: CFC, app: URI scheme

Mark Baker
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).

It seems to me that the innovation in app: is the use of UUID in the
authority component. I agree that this is valuable in some contexts,
but wonder why that can't be used with a DNS name. So instead of;

app://c13c6f30-ce25-11e0-9572-0800200c9a66/index.html

why not this?

http://c13c6f30-ce25-11e0-9572-0800200c9a66.localhost/index.html

Reply | Threaded
Open this post in threaded view
|

Re: CFC, app: URI scheme

Marcos Caceres-4


On Friday, November 1, 2013 at 8:58 PM, Mark Baker wrote:

> 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).
>  
> It seems to me that the innovation in app: is the use of UUID in the
> authority component. I agree that this is valuable in some contexts,
> but wonder why that can't be used with a DNS name. So instead of;
>  
> app://c13c6f30-ce25-11e0-9572-0800200c9a66/index.html
>  
> why not this?
>  
> http://c13c6f30-ce25-11e0-9572-0800200c9a66.localhost/index.html
That would have always been my preference too (I even argued the same thing for a long long time)! But it would mean packing a HTTP server into the runtime - instead of the fairly dumb thing that app:// is. Everyone that I’ve ever worked with on these kinds of engines hasn’t wanted to do that (or has found the whole thing problematic because it meant setting it a the system level, etc.). So yeah - it’s totally the right solution, imo also, but it’s just hasn’t happened at the implementation level :( Thus, I’m here again pushing for app:// (which is just widget: in disguise).  
 
--  
Marcos Caceres




Reply | Threaded
Open this post in threaded view
|

Re: CFC, app: URI scheme

Gannon Dick
In reply to this post by Mark Baker
Good point, Mark, and besides isn't a UUID a "dotless domain" ?
(now prohibited) http://www.icann.org/en/groups/board/documents/resolutions-new-gtld-13aug13-en.htm#1
--------------------------------------------
On Fri, 11/1/13, Mark Baker <[hidden email]> wrote:

 Subject: Re: CFC, app: URI scheme
 To: "Marcos Caceres" <[hidden email]>
 Cc: [hidden email]
 Date: Friday, November 1, 2013, 3:58 PM
 
 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).
 
 It seems to me that the innovation in app: is the use of
 UUID in the
 authority component. I agree that this is valuable in some
 contexts,
 but wonder why that can't be used with a DNS name. So
 instead of;
 
 app://c13c6f30-ce25-11e0-9572-0800200c9a66/index.html
 
 why not this?
 
 http://c13c6f30-ce25-11e0-9572-0800200c9a66.localhost/index.html
 
 

Reply | Threaded
Open this post in threaded view
|

Re: CFC, app: URI scheme

John Cowan-3
In reply to this post by Mark Baker
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.

--
John Cowan   [hidden email]  http://www.ccil.org/~cowan
Most languages are dramatically underdescribed, and at least one is
dramatically overdescribed.  Still other languages are simultaneously
overdescribed and underdescribed.  Welsh pertains to the third category.
        --Alan King

Reply | Threaded
Open this post in threaded view
|

Re: CFC, app: URI scheme

Marcos Caceres-4


On November 1, 2013 at 7:12:08 PM, John Cowan ([hidden email]) 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