- From: Paul Libbrecht <paul@hoplahup.net>
- Date: Tue, 20 Oct 2015 18:46:17 +0200
- To: Daniel Buchner <dabuchne@microsoft.com>
- CC: "public-webapps@w3.org" <public-webapps@w3.org>
- Message-ID: <56266FD9.1060800@hoplahup.net>
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, 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/. > 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 >
Received on Wednesday, 21 October 2015 14:55:34 UTC