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

Top posting because this is a reply to no one in-particular, but since
the chairs have advised already to take this to
http://discourse.wicg.io/ - is there a reason there's still so much
discussion here and none there?

On Wed, Oct 21, 2015 at 11:33 AM, Daniel Buchner <dabuchne@microsoft.com> wrote:
> 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>
> 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
> 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, 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>
> Cc: 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
> 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
> 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/. 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
>
>



-- 
Brian Kardell :: @briankardell :: hitchjs.com

Received on Wednesday, 21 October 2015 15:39:58 UTC