Re: Google Maps URL Scheme

Robin,

please enlighten us.
Thus far, I have always seen protocol mapping similar to media-type-handlers. A name, an application which maybe users can change.
This has both an advantage (freedom) and a drawback (freedom); extensibility is probably the way forward.

But I've been surprised to see that a YouTube http URL on my Android was offered to open by YouTube, but another http URL was not.
Is there an evaluation capability (that would say for example that URLs of this pattern I can support)?

Would the google-maps URL, if used or available on Android, then possibly be specially responded to by the Pizza-Hut application in case the search string contains the word pizza (and Pizzen for a German context, and...)?

paul




Le 17 déc. 2012 à 11:37, Robin Berjon a écrit :

> On 14/12/2012 23:46 , Noah Mendelsohn wrote:
>> On 12/14/2012 11:37 AM, Robin Berjon wrote:
>>> No, a media type is just as bad, only one step removed. If the
>>> implementation is in HTML (as it's likely and getting likelier to be)
>>> then
>>> all you've done is pushed the masquerading to another layer.
>> 
>> I'm not convinced. Media types and schemes affect different parts of the
>> space. Schemes show up directly in the names that are used for linking,
>> and they require hooks in the corresponding dispatch tables. When you
>> use a scheme other than http, you cannot change your mind about the
>> formats or protocols to be used without changing all the URIs and links.
>> With http, you can have a link to a portion of a map (to use the example
>> we're talking about), and have it come back as an interactive
>> application sometimes, and a gif others. My impression is that Google
>> Maps does exactly this in supporting small devices with non-JavaScript
>> browsers.
> 
> Sure, but by piggy-backing on media types instead what you get in the above case is someone using text/vnd.whoever.html or image/vnd.whoever.gif instead of the real content types. While the precise problems you've created with either approach are different, I don't think that one can easily be shown to be less problematic than the other. They're both kludges that attempt to dispatch correctly based on the wrong extension mechanism.
> 
> Architecturally, what you want here is for sender and receiver not to have to be tied to the same mapping service (maybe you're using a desktop device and OS on which yours works great but it really fails on my mobile with a different system). The exchange that's taking place is "view a position on a map". Both parties should be able to use different mapping solutions for the same content. For that, you want something that has the architectural properties of intents.
> 
> In order to be linkable, that might require an "intent:" scheme capturing the intent's content, but that's a relatively simple addition once you have the basics of the intentional architecture nailed.
> 
> -- 
> Robin Berjon - http://berjon.com/ - @robinberjon
>

Received on Monday, 17 December 2012 12:13:45 UTC