W3C home > Mailing lists > Public > public-webapps@w3.org > October to December 2015

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

From: Aymeric Vitte <vitteaymeric@gmail.com>
Date: Thu, 22 Oct 2015 13:15:22 +0200
To: public-webapps@w3.org
Message-ID: <5628C54A.9070606@gmail.com>
Whatever we call it the "protocol worker" exchanges data between two
apps, and as I suggested the data can be a Web Component itself, part of
it, what is needed by the receiving app, the result can be anything too,
it can be passed back to the calling app, be HTML code, be a customized
Web Component, etc, etc so I believe this is doing the copy and paste
mentionned below, I don't see any limitation and I don't see any
technical difficulty to spec this.

Probably the Intents spec should be restarted based on this instead of
being closed.

Le 21/10/2015 17:33, Daniel Buchner a écrit :
> 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>
>> *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 <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,326^th 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
>>
> 

-- 
Get the torrent dynamic blocklist: http://peersm.com/getblocklist
Check the 10 M passwords list: http://peersm.com/findmyass
Anti-spies and private torrents, dynamic blocklist: http://torrent-live.org
Peersm : http://www.peersm.com
torrent-live: https://github.com/Ayms/torrent-live
node-Tor : https://www.github.com/Ayms/node-Tor
GitHub : https://www.github.com/Ayms
Received on Thursday, 22 October 2015 11:16:02 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 18:14:58 UTC