

Apps and Web URLs: Perfect Together - BarkMore
http://joehewitt.com/2011/10/06/apps-and-web-urls-perfect-together

======
mcmatterson
This is so wrong, I don't even know where to begin. The _entire_ point of URLs
is that they're just that -- Universal. Requiring a specific application in
order to consume a URL is just as asinine as User Agent sniffing to enforce an
'IE Only' policy (and you're lying if you say that ended well).

Perhaps consuming based on Content-Type headers would be a better way to
attack this (legitimate) problem. Certainly in the early days of the web,
that's how it was done (want to enjoy the latest VRML? Install plugin 'x').
Adding a layer of abstraction on top of URLs that tries to mediate this is
just altogether wrong, I think.

Debate welcome. I'm mostly just thinking out loud here.

~~~
lygaret
See my comment above, but I'm pretty sure you have his argument backwards; we
already _do_ have application specific URLs in iOS, and wouldn't it be nice if
that weren't the case?

------
zokier
He says that service-specific URLs are not portable, but I don't see any
reason why that would be the case. I mean, most platforms supports registering
handlers for arbitrary schemes. The only piece I see missing is the ability to
register a web app as a URL handler, but that should be almost trivial to
solve. Already if I click a mailto:-link in Firefox, I have the choice of
using Gmail, so generalizing that shouldn't be too difficult.

edit: apparently Firefox already does "Web-based protocol handlers", which
allow web apps to register arbitrary URL-schemes. So basically only thing
needed to make fb-URLs to work with browsers is such handler for the Facebook
web app.

edit2: <http://zokier.net/fburl/> implements aforementioned fb-URL handler. If
you register that page to handle fb://-urls in Firefox, and register Firefox
to those urls in Windows, then they function globally correctly.

------
chime
Here's a site to publish your iOS-specific app URLs:
<http://www.handleopenurl.com/>

Until apps start owning URLs, everyone can publish their app capabilities here
and call other apps (like Tweetbot) from their apps.

------
kefs
Why am i required to enable javascript just to read text on Joe Hewitt's blog?
No degradation at all? :(

~~~
joehewitt
I'm using a fairly experimental JavaScript-driven system right now. It's
totally overkill for a blog, but it's my blog and I can do stuff like this for
fun. No offense, but if you disable JavaScript, you get what you deserve.

~~~
icebraining
_> you get what you deserve_

A more secure and tracking-free experience?

By the way, nothing against that (although I probably won't bother enabling
it), but is it doing User-Agent sniffing? Because here in Firefox 6 it loads a
normal HTML version.

~~~
pasbesoin
I love how the industry can spend a decade advocating the separation of form
and content, and then in a handful of years go to completely co-mingling the
two, at least and especially from the end user perspective.

I disable Javascript out of necessity. Having cleaned enough garbage off of
others' computers, and having struggled long enough to pay attention despite
the "blinkenlights", I find I really have no alternative.

Your choice, Joe. Fine, although I don't particularly appreciate the snarky
rhetoric. (I find the combination of "No offense..." and "you get what you
deserve" to be a rhetorical ploy.)

------
drivebyacct2
This has been a feature of Android since launch, it's part of the w3c spec for
protocol specific handlers (and is already implemented in Chrome Dev [Google
Calendar offered to handle all webcal: links for me]), and it will be better
suited via Web Intents in the coming months.

Also, there's really no explaination by the author as to how
fb://profile/drivebyacct2 is any better than
<http://facebook.com/profile/drivebyacct2>. Now there will be a landrush of
people trying to claim protocol prefixes now too? Why bother, domains are
already intrensic enough to online brands, why create a whole new area to deal
with? Not to mention user confusion. Yes, that's "eff-bee colon slash slash",
"no, don't put www first", etc.

~~~
lygaret
I'm pretty sure you've got his argument backwards:

1\. We already _do_ have fb://profile/account, it's the app specific URL
registered in the iOS app to open the Facebook app.

2\. What he's saying is "Why can't you register <http://facebook.com/profile>
on iOS to open the facebook app?" That would mean that we explicitly _don't_
have a protocol landrush.

3\. A solution might be a service that takes a web url, and returns an app
url, so that if the web url has an app equivalent, we never have to know it;
the app functions as we expect, and we don't introduce something above and
beyond the web URLs we know and love.

~~~
drivebyacct2
1\. That's iOS and I have no idea why anyone would want that. Like really,
what value does that add?

2\. Yes, like I said, Android has already implemented that. I think it's a
fine idea. I love that I can click on Youtube links and choose to open it in
Dolphin, the YouTube app, or the YouTube downloader app.

3\. Why would the web service take the URL. Like I already said, model this
off of browser protocol handlers and Web Intents. Let web application register
as possible handlers, let the application choose whether to open in a webpage,
or another web app that is capable of consuming and understanding those URLs
(which is exactly how it happens in Android). Again, how is an "app url" any
more useful than a regular URL in this regard?

~~~
icebraining
I think the point is to achieve what Android has without waiting for Apple to
implement it. Since iOS app devs are stuck with internal URIs, a translation
webservice would alleviate the problem.

~~~
drivebyacct2
But this would still require OS level abstraction to even submit the web URLs
to the webservice to look up an app-specific URL. Unless I'm missing
something.

