Re: Proposal: External Protocol Handling

OK. Thanks for the clarifications, Konstantin & Ben!

Sincerely,
    James Greene



On Mon, Mar 31, 2014 at 12:55 PM, Ben Johnson <Ben.Johnson@citrix.com>wrote:

> Kosta has pretty much covered it. Web Intents as well as current browser
> implementations are heavily geared towards web-based protocol handling,
> potentially at the expense of external handlers.
>
> The final question in my initial e-mail " Should it be better aligned with
> web-based protocol handling? If so, how?" was intended to allude to that -
> I probably should have been more specific.
>
>
> -----Original Message-----
> From: Konstantin Welke
> Sent: Monday, March 31, 2014 7:01 AM
> To: James Greene; Ben Johnson
> Cc: public-webapps@w3.org; Kenneth Auchenberg; Mathieu Hofman
> Subject: Re: Proposal: External Protocol Handling
>
> Hi!
>
> I think the biggest difference is that web intents work between web pages,
> whereas this is used to launch installed programs on the user’s computer.
>
> Think about this use case: A web page with a list of ssh hosts. When you
> click on a link, the JS on the page calls
> navigator.launchUri(“ssh://hostname”) to try to launch your SSH agent. If
> a handler for the “ssh://“ protocol is installed, it presents the user with
> a dialog window to ask whether they want to launch their SSH client (e.g.
> “PuTTY" on Windows, ssh in a terminal on Mac, Unix*).
>
> If the user accepts, the SSH client is launched and the JS successCallback
> is executed; If the user rejects or no SSH client is registered, the SSH
> client is not launched and the noHandlerCallback is executed.
>
> Currently, one can do that using a plain link or an iframe - however the
> user experience is pretty bad if e.g. no protocol handler client is
> installed (depending on the browser). Each browser has different gotchas
> and limitations that we currently need to work around.
>
> We would like to have a stable, well-defined API for this that also allows
> to handle the “user declined / protocol handler is not installed” case
> gracefully. As an example, the web page could show a UI to tell the user
> how to install an SSH client.
>
> Cheers,
> Kosta
>
> PS: Sorry for the long signature...
> --
> Konstantin Welke
> Senior Software Developer
> Citrix Online Germany GmbH | Erzbergerstr. 117 | D-76133 Karlsruhe
> T: +49 721 3544990 | F: +49 721 354499624 | M: +49 151 23429318
> konstantin.welke@citrix.com http://www.citrixonline.com <
> http://www.citrixonline.com/>
>
> Work better. Live better.
> Citrix Online Germany GmbH | Erzbergerstr. 117 | D-76133 Karlsruhe
> Geschäftsführer: Tommy Ahlers | Michael DiFilippo | David Zalewski Sitz
> der Gesellschaft: Karlsruhe | Registergericht: Amtsgericht Mannheim HRB
> 713721 Citrix Online UK Ltd <http://www.citrixonline.com/imprint-en.tmpl>
>
>
> On Monday, March 31, 2014 at 3:04 PM, James Greene <
> james.m.greene@gmail.com> wrote:
>
> Would this be similar to the Web Intents spec proposal that Google was
> championing (based on Android Intents)?
>
> Sincerely,
>     James Greene
>
> On Thu, Mar 27, 2014 at 5:52 PM, Ben Johnson <Ben.Johnson@citrix.com>
> wrote:
>
> Hi all,
>
> I’ve been working on a draft specification for a creating a dedicated
> cross-browser external protocol launching standard based on the behavior of
> msLaunchUri in Internet Explorer.
>
> The draft is here:
> http://bengjohnson.github.io/ExternalProtocolSpecification.html
> <http://bengjohnson.github.io/ExternalProtocolSpecification.html>
>
> I’m looking for feedback from the web app group members on:
>
> ·
> What major concerns to you have with the overall approach?
> o
> Do you feel there are insufficient motivating factors for a change to be
> made?
> o
> Are there unstated concerns missing from the document?
> ·
> What level of detail are you expecting for a complete proposal?
> ·
> Should it be better aligned with web-based protocol handling? If so, how?
> ·
> And of course, any particular issues with the document in its current form.
>
> Thanks,
> Ben
>
>
>
>
>
>
>
>