Re: App-to-App interaction APIs - one more time, with feeling

I believe you may be conflating two rather distinct code activities. What this API (or one like it) would provide is the ability for an app to form any sort of request, whether it originates via user input or just of its own code/needs, and have the user's preferred handler deal with the request.

You keep talking about copy/paste of a math formula as if it's a gotcha - but at this point, I have no idea how it affects this API. But to better understand, let me address your hypothetical in the way the proposed API would deal with it:

Let's say an app had a text input for math formulas, and the user entered one via typing, copy/paste, speech, whatever, it doesn't matter. The app itself doesn't know how to handle math formulas, so it creates a protocol worker to open a connection to the user's web+math provider. Let's imagine the user has preselected Wolfram Alpha. A connection would be opened between the app and Wolfram, the app then sends a request/payload to Wolfram, and Wolfram does whatever the generally agreed upon action is for handling this type of web+math request. Once Wolfram is finished, it sends back response data over the protocol handler connection, to the app.

I'm *really* trying to understand what you believe this API lacks for handling the flow listed above. To end the status quo of every site on the Web hard coding its activities to a few lucky providers who out spend other to win the dev marketing Olympics, you must have a mechanism in place that allows users to add, select, and manage providers, and connect to the user's providers for handling of associated activities - full stop.

Please consider carefully the above detailed explanation and let me know if there's anything left that's unclear.

- Daniel



On Wed, Oct 21, 2015 at 7:55 AM -0700, "Paul Libbrecht" <paul@hoplahup.net<mailto:paul@hoplahup.net>> wrote:

Hello Daniel,

Maybe things can be said like this: copy and paste lets you choose where you paste and what you paste, protocol handlers don't. Here's a more detailed answer.

With a mathematical formula information at hand, you can do a zillion things, assuming there's a single thing is not reasonable, even temporarily. For example, a very normal workflow could be the following: copy from a web-page, paste into a computation engine, adjust, derive, paste into a dynamic geometry tool, then paste one of the outputs into a mail.
Providing configurable protocol handlers, even to the finest grade, is not a solution to this workflow I feel.

Providing dialogs to ask the user where he wants the information at hand to be opened gets closer but there's still the idea of selection and cursor which protocol handlers do not seem to be ready to perform.

However, I believe that copy-and-paste (and drag-and-drop) is part of an app-to-app interaction APIs.

Paul


Daniel Buchner<mailto:dabuchne@microsoft.com>
20 octobre 2015 18:36
I’m trying to understand exactly why you see your example (“there was a person who invented a "math" protocol handler. For him it meant that formulæ be read out loud (because his mission is making the web accessible to people with disabilities including eyes) but clearly there was no way to bring a different target.”) as something this initiative is blocked by or cannot serve.

If you were to create a custom, community-led protocol definition for math equation handling, like web+math, apps would send a standard payload of semantic data, as defined here: http://schema.org/Code<https://na01.safelinks.protection.outlook.com/?url=http%3a%2f%2fschema.org%2fCode&data=01%7c01%7cdabuchne%40microsoft.com%7c0a436061fdf14fb9153b08d2da279a00%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=n0RE%2bC%2bPtCK1DhaEiKibXE%2b%2bTrQcGs1PZd1ppxU4%2bIg%3d>, and it would be handled by whatever app the user had installed to handle it. Given the handler at the other end is sending back data that would be displayed in the page, there’s no reason JAWS or any other accessibility app would be blocked from reading its output – on either side of the connection.

I can’t really make sense of this part of your email, can you clarify? --> “Somehow, I can't really be convinced by such a post except asking the user what is the sense of a given flavour or even protocol handler which, as we know, is kind of error-prone. Agree?” Asking the user what sense of a given protocol? Are you saying we can’t ask users what apps they want to have handle various actions? If so, we do this all the time, in every OS on the planet, and I wouldn’t say that simple process is error prone. Maybe I am misunderstanding you?

- Daniel

From: Paul Libbrecht [mailto:paul@hoplahup.net]
Sent: Sunday, October 18, 2015 9:38 AM
To: Daniel Buchner <dabuchne@microsoft.com><mailto:dabuchne@microsoft.com>
Cc: public-webapps@w3.org<mailto:public-webapps@w3.org>
Subject: Re: App-to-App interaction APIs - one more time, with feeling

Daniel,

as far as I can read the post, copy-and-paste-interoperability would be a "sub-task" of this.
It's not a very small task though.
In my world, E.g., there was a person who inventend a "math" protocol handler. For him it meant that formulæ be read out loud (because his mission is making the web accessible to people with disabilities including eyes) but clearly there was no way to bring a different target.

Somehow, I can't really be convinced by such a post except asking the user what is the sense of a given flavour or even protocol handler which, as we know, is kind of error-prone. Agree?

paul

PS: I'm still struggling for the geo URL scheme to be properly handled but it works for me in a very very tiny spectrum of apps (GMaps > Hand-edited-HTML-in-Mails-through-Postbox > Blackberry Hub > Osmand). This is certainly a good example of difficult sequence of choices.



Paul Libbrecht<mailto:paul@hoplahup.net>
18 octobre 2015 18:38
Daniel,

as far as I can read the post, copy-and-paste-interoperability would be a "sub-task" of this.
It's not a very small task though.
In my world, E.g., there was a person who inventend a "math" protocol handler. For him it meant that formulæ be read out loud (because his mission is making the web accessible to people with disabilities including eyes) but clearly there was no way to bring a different target.

Somehow, I can't really be convinced by such a post except asking the user what is the sense of a given flavour or even protocol handler which, as we know, is kind of error-prone. Agree?

paul

PS: I'm still struggling for the geo URL scheme to be properly handled but it works for me in a very very tiny spectrum of apps (GMaps > Hand-edited-HTML-in-Mails-through-Postbox > Blackberry Hub > Osmand). This is certainly a good example of difficult sequence of choices.


Daniel Buchner<mailto:dabuchne@microsoft.com>
14 octobre 2015 18:33
Hey WebAppers,

Just ran into this dragon for the 1,326th time, so thought I would do a write-up to rekindle discussion on this important area of developer need the platform currently fails to address: http://www.backalleycoder.com/2015/10/13/app-to-app-interaction-apis/<https://na01.safelinks.protection.outlook.com/?url=http%3a%2f%2fwww.backalleycoder.com%2f2015%2f10%2f13%2fapp-to-app-interaction-apis%2f&data=01%7c01%7cdabuchne%40microsoft.com%7c0a436061fdf14fb9153b08d2da279a00%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=J8CqjOqDNkQKIzjeubo2j%2bLMlxTObSsrDG4WqogBSgo%3d>. We have existing APIs/specs that get relatively close, and my first instinct would be to leverage those and extend their capabilities to cover the broader family of use-cases highlighted in the post.

I welcome your ideas, feedback, and commentary,

- Daniel