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

[Aymeric Vitte]

 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:p...@hoplahup.net]
>> *Sent:* Sunday, October 18, 2015 9:38 AM
>> *To:* Daniel Buchner <dabuc...@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:p...@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:dabuc...@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=01%7c01%7cdabuchne%40microsoft.com%7c0a436061fdf14fb9153b08d2da279a00%7c72f988bf86f141af91ab2d7cd011db47%7c1=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

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

[Brian Kardell]

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 <dabuc...@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" <p...@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 err

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

[Daniel Buchner]

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" 
<p...@hoplahup.net<mailto:p...@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:dabuc...@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=01%7c01%7cdabuchne%40microsoft.com%7c0a436061fdf14fb9153b08d2da279a00%7c72f988bf86f141af91ab2d7cd011db47%7c1=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:p...@hoplahup.net]
Sent: Sunday, October 18, 2015 9:38 AM
To: Daniel Buchner <dabuc...@microsoft.com><mailto:dabuc...@microsoft.com>
Cc: public-webapps@w3.org<mailto:public-webapps@w3.org>
Subject: Re: App-to-App interaction APIs - one more time, wit

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

[Daniel Buchner]

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:p...@hoplahup.net]
Sent: Sunday, October 18, 2015 9:38 AM
To: Daniel Buchner <dabuc...@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.


Daniel Buchner<mailto:dabuc...@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=01%7c01%7cdabuchne%40microsoft.com%7cb93b5f788520457129d208d2d7da91a0%7c72f988bf86f141af91ab2d7cd011db47%7c1=IxbwQKRykbEKCDtFAsFUtEEETfQXt7XUsVxt7iGy6fw%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

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

[Anders Rundgren]

On 2015-10-18 19:09, Aymeric Vitte wrote:



Le 17/10/2015 16:19, Anders Rundgren a écrit :

Unless you work for a browser vendor or is generally "recognized" for some
specialty, nothing seems to be of enough interest to even get briefly
evaluated.



Right, that's a deficiency of the W3C/WHATWG/whatever specs process,
where people well seated in their big companies/org comfortable chairs
lack imagination, innovation, are very long to produce anything and just
spec for themselves things that become obsolete as soon as they have
released it, or things that just never match the reality and general use
cases, and they generally disconsider other opinions, although they
recognize usually at the end that they messed up, then they respecc it
and the loop starts again.


Regarding App-to-App interaction I'm personally mainly into the
Web-to-Native variant.


That's a very poor system, I think you are still in your long never
ending quest of seeking for "something in the web that could match what
you want to do" but probably it's not that one.

Do people here mean that we are going forever to exchange text, images,
files, stuff like this only?

That's the vision?


I can't speak for people here in general but my vision (FWIW) is already
fairly well in place:

https://test.webpki.org/webpay-merchant

Yes, the are some folks who claim that this will eventually be possible doing
with "pure" Web tech but maybe the market doesn't care that much about purity?
Particularly not if it takes 5-10 years to achieve.  Too little too late.

One doesn't have to think very hard to realize that Apple and Google won't
build wallets for iOS and Android respectively and then build another set
for the Web.  It would be a very confusing user-experience, poor use of
development resources etc.

Note: wallets i just one app among many.

Anders


Can't we share Web Components? Which can be any app with the possibility
to interact with it?

That's what for example the Web Intents should do, again you should not
close the group.

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

[Aymeric Vitte]

Please stop on your side giving lessons again and stop trying to
isolate/elude my initial answer, and refrain people on this list not to
be insulting first.

This one was not insulting, just a general consideration and you should
consider it.

But indeed, back to the "in-scope" technical discussion copied below,
waiting for comments, unless you cut it or try to distract it again.

"
This approach [1] and [2] looks quite good, simple and can cover all cases.

I don't know if we can call it a Web Component really for all cases but
let's call it as such.

In [2] examples the Bio component could be extracted to be passed to the
editor for example and/or could be shared on fb, and idem from fb be
edited, shared, etc

Or let's imagine that I am a 0 in web programming and even Web
Components are too complicate for me, I put an empty Google map and
edit/customize it via a Google map editor, there is [3] maybe too but
anyway the use cases are legions.

The Intent service would then be a visible or a silent Web Component
discussing with the Intent client using postMessage.

Maybe the process could  be instanciated with something specific in href
(as suggested in [2] again) but an Intent object still looks mandatory.

But in case of visible Intent service, the pop-up style looks very ugly
and old, something should be modified so it seems to appear in the
calling page, then the Intent service needs to have the possibility to
become invisible (after login for example).

I don't see any technical difficulty to spec and implement this (except
maybe how to avoid the horrible pop-up effect) and this covers everything."



Le 18/10/2015 20:49, Chaals McCathie Nevile a écrit :
> On Sun, 18 Oct 2015 19:09:42 +0200, Aymeric Vitte
>  wrote:
> 
>> Le 17/10/2015 16:19, Anders Rundgren a écrit :
>>> Unless you work for a browser vendor or is generally "recognized" for
>>> some specialty, nothing seems to be of enough interest to even get
>>> briefly evaluated.
>>>
>>
>> Right, that's a deficiency of the W3C/WHATWG/whatever specs process,
>> where people well seated in their big companies/org comfortable chairs
>> lack imagination, innovation, are very long to produce anything and just
>> spec for themselves things that become obsolete as soon as they have
>> released it, or things that just never match the reality and general use
>> cases, and they generally disconsider other opinions, although they
>> recognize usually at the end that they messed up, then they respecc it
>> and the loop starts again.
> 
> To be clear, this is a clear example of the lack of civility that I
> referred to earlier, which is inappropriate as noted in the Workmode
> document: https://github.com/w3c/WebPlatformWG/blob/gh-pages/WorkMode.md
> 
> Please refrain from insulting people (whether individually or as a
> group), and stick to in-scope technical discussion.
> 
> For the chairs
> 
> Chaals
> 

-- 
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

Re: Making progress with items in Web Platform Re: App-to-App interaction APIs - one more time, with feeling

[Chaals McCathie Nevile]

Offlist.

On Sat, 17 Oct 2015 19:36:54 +0200, Anders Rundgren
 wrote:


On 2015-10-17 17:58, Chaals McCathie Nevile wrote:


Regarding App-to-App interaction I'm personally mainly into the
Web-to-Native variant.


As I already pointed out to Daniel, this stuff is not in the current  
scope

of the group, and you should work on it in the context of e.g. the Web
Incubator Community Group, where it is relevant to their scope.


As I wrote, this particular feature is already in Chrome and is now  
being implemented by Microsoft and Mozilla.


That doesn't make it part of the current scope of the group.

It is therefore off-topic, and having been asked to take the discussion
where it is in scope, please refrain from continuing it on webapps.

cheers

--
Charles McCathie Nevile - web standards - CTO Office, Yandex
   cha...@yandex-team.ru - - - Find more at http://yandex.com

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

[Paul Libbrecht]

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,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
>

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

[Aymeric Vitte]

Le 17/10/2015 16:19, Anders Rundgren a écrit :
> Unless you work for a browser vendor or is generally "recognized" for some
> specialty, nothing seems to be of enough interest to even get briefly
> evaluated.
> 

Right, that's a deficiency of the W3C/WHATWG/whatever specs process,
where people well seated in their big companies/org comfortable chairs
lack imagination, innovation, are very long to produce anything and just
spec for themselves things that become obsolete as soon as they have
released it, or things that just never match the reality and general use
cases, and they generally disconsider other opinions, although they
recognize usually at the end that they messed up, then they respecc it
and the loop starts again.

> Regarding App-to-App interaction I'm personally mainly into the
> Web-to-Native variant.

That's a very poor system, I think you are still in your long never
ending quest of seeking for "something in the web that could match what
you want to do" but probably it's not that one.

Do people here mean that we are going forever to exchange text, images,
files, stuff like this only?

That's the vision?

Can't we share Web Components? Which can be any app with the possibility
to interact with it?

That's what for example the Web Intents should do, again you should not
close the group.

-- 
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

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

[Paul Libbrecht]

Anders Rundgren wrote:
> Unless you work for a browser vendor or is generally "recognized" for
> some
> specialty, nothing seems to be of enough interest to even get briefly
> evaluated. 
Maybe the right thing is assemble "user representative" groups and be
enough heard on such places as this mailing list?

However, the problem with a question as the one of this thread is that
the answers can be hugely multi-facetted.

I do believe that the W3C process is sufficiently open to let each user
speak out loud and be heard on this mailing list (public-webapps@w3.org)
even if there are side actions trying to make things more friendly (such
as the WhatWG) or there are people believing that the W3C is too much
corporations oriented.

paul

Re: Making progress with items in Web Platform Re: App-to-App interaction APIs - one more time, with feeling

[Aymeric Vitte]

Le 17/10/2015 17:58, Chaals McCathie Nevile a écrit :
> Aymeric, that could apply to you to - and in fact the requirement to
> behave courteously is a general one for this list and others of the Web
> Platform WG

Replying only to this for now, you don't know what you are talking about
and don't try to give lessons about things you don't know, courtesy is
something that other people should learn on this list.

And don't change the initial subject of this thread or open a new one.

But don't worry, unlike other people on this list, I will always remain
polite.

Now, please discontinue this thread and let's talk the original one.

I would like to know what inspired W3C folks think about what I wrote,
this is short but everything is in there.

-- 
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

Re: Making progress with items in Web Platform Re: App-to-App interaction APIs - one more time, with feeling

[Anders Rundgren]

On 2015-10-17 17:58, Chaals McCathie Nevile wrote:


Regarding App-to-App interaction I'm personally mainly into the
Web-to-Native variant.


As I already pointed out to Daniel, this stuff is not in the current scope
of the group, and you should work on it in the context of e.g. the Web
Incubator Community Group, where it is relevant to their scope.


As I wrote, this particular feature is already in Chrome and is now being 
implemented by Microsoft and Mozilla.

Anders



chaals, for the chairs.


Here the browser vendors have reportedly [1,2] decided to implement
Google's
Native Messaging API "as is" without any discussions in related W3C
forums,
something they will surely regret because it has a long list of
shortcomings,
ranging from a difficult deployment scheme to limited functionality and
performance issues, not to mention a highly deficient security model:
https://lists.w3.org/Archives/Public/public-webappsec/2015Oct/0071.html

That the browsers vendors have gotten major push-backs after removing
their previous extension schemes (NPAPI, ActiveX) is obvious, but that
doesn't motivate rushing into crude workarounds:
http://www.cnet.com/news/google-paves-over-hole-left-by-chrome-plug-in-ban/

Anders

1] https://wiki.mozilla.org/WebExtensions#Additional_APIs
2]
http://www.slashgear.com/project-spartan-is-now-edge-and-will-have-chrome-extensions-29381422/


Ccing the authors of [1], [2] and [3] if there is still an interest.



at this stage we don't have a deliverable for this work - i.e. the W3C
members haven't approved doing something like this in Web Platform
working
group. Given that people repeatedly attempt to do it, I think the
conversation is worth having. Personally I think this is something the
Web needs


Indeed, that will be more than time to do so, but the current view of
the main actors or past specs seems a kind of narrowed and not very
imaginative/innovative, I don't think you should close the web intents
task force [5] but restart it on new bases.

This approach [1] and [2] looks quite good, simple and can cover all
cases.

I don't know if we can call it a Web Component really for all cases but
let's call it as such.

In [2] examples the Bio component could be extracted to be passed to the
editor for example and/or could be shared on fb, and idem from fb be
edited, shared, etc

Or let's imagine that I am a 0 in web programming and even Web
Components are too complicate for me, I put an empty Google map and
edit/customize it via a Google map editor, there is [3] maybe too but
anyway the use cases are legions.

That's incredible that nobody can see this and that [1] did not get any
echo (this comment I especially dedicate it to some people that will
recognize themselves about some inappropriate comments, not to say more,
they made regarding the subject related to the last paragraph of this
post).

The Intent service would then be a visible or a silent Web Component
discussing with the Intent client using postMessage.

Maybe the process could  be instanciated with something specific in href
(as suggested in [2] again) but an Intent object still looks mandatory.

But in case of visible Intent service, the pop-up style looks very ugly
and old, something should be modified so it seems to appear in the
calling page, then the Intent service needs to have the possibility to
become invisible (after login for example).

I don't see any technical difficulty to spec and implement this (except
maybe how to avoid the horrible pop-up effect) and this covers
everything.



If that happens the next step is to change our charter.

That is an administrative thing that takes a few weeks (largely to
ensure
we get the IPR protection W3C standards can enjoy, which happens
because
we spend the time to do the admin with legal processes) if there is
some
broad-based support.


Unfortunately, despite of our efforts and patience, due to the lack of
agreement on this matter with the related W3C members, unless people
decide to restrict Intents to some trivial edit, share uses of simple
images, text, files, which looks quite limited (but surprisingly seems
enough for Microsoft, Mozilla and Google) and will necessarily end-up
redoing the spec again several years later, the specs will inevitably
cross again the path of the patent you know [4], for parts related to
the extraction mechanisms that time, which anyway the web will one day
implement.


[1]
https://lists.w3.org/Archives/Public/public-web-intents/2014Oct/0001.html
[2]
http://dev.mygrid.org.uk/blog/2014/10/you-want-to-do-what-theres-an-app-for-that/
[3] https://lists.w3.org/Archives/Public/public-web-intents/2015Feb/
[4]
https://lists.w3.org/Archives/Public/public-webapps/2015AprJun/0911.html
[5]
https://lists.w3.org/Archives/Public/public-web-intents/2015Oct/.html

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

[Anders Rundgren]

On 2015-10-16 18:00, Aymeric Vitte wrote:

Well, since I was on the list, I took the liberty of commenting a bit on this.

Unless you work for a browser vendor or is generally "recognized" for some
specialty, nothing seems to be of enough interest to even get briefly evaluated.

Regarding App-to-App interaction I'm personally mainly into the Web-to-Native 
variant.

Here the browser vendors have reportedly [1,2] decided to implement Google's
Native Messaging API "as is" without any discussions in related W3C forums,
something they will surely regret because it has a long list of shortcomings,
ranging from a difficult deployment scheme to limited functionality and
performance issues, not to mention a highly deficient security model:
https://lists.w3.org/Archives/Public/public-webappsec/2015Oct/0071.html

That the browsers vendors have gotten major push-backs after removing
their previous extension schemes (NPAPI, ActiveX) is obvious, but that
doesn't motivate rushing into crude workarounds:
http://www.cnet.com/news/google-paves-over-hole-left-by-chrome-plug-in-ban/

Anders

1] https://wiki.mozilla.org/WebExtensions#Additional_APIs
2] 
http://www.slashgear.com/project-spartan-is-now-edge-and-will-have-chrome-extensions-29381422/


Ccing the authors of [1], [2] and [3] if there is still an interest.



at this stage we don't have a deliverable for this work - i.e. the W3C
members haven't approved doing something like this in Web Platform working
group. Given that people repeatedly attempt to do it, I think the
conversation is worth having. Personally I think this is something the
Web needs


Indeed, that will be more than time to do so, but the current view of
the main actors or past specs seems a kind of narrowed and not very
imaginative/innovative, I don't think you should close the web intents
task force [5] but restart it on new bases.

This approach [1] and [2] looks quite good, simple and can cover all cases.

I don't know if we can call it a Web Component really for all cases but
let's call it as such.

In [2] examples the Bio component could be extracted to be passed to the
editor for example and/or could be shared on fb, and idem from fb be
edited, shared, etc

Or let's imagine that I am a 0 in web programming and even Web
Components are too complicate for me, I put an empty Google map and
edit/customize it via a Google map editor, there is [3] maybe too but
anyway the use cases are legions.

That's incredible that nobody can see this and that [1] did not get any
echo (this comment I especially dedicate it to some people that will
recognize themselves about some inappropriate comments, not to say more,
they made regarding the subject related to the last paragraph of this post).

The Intent service would then be a visible or a silent Web Component
discussing with the Intent client using postMessage.

Maybe the process could  be instanciated with something specific in href
(as suggested in [2] again) but an Intent object still looks mandatory.

But in case of visible Intent service, the pop-up style looks very ugly
and old, something should be modified so it seems to appear in the
calling page, then the Intent service needs to have the possibility to
become invisible (after login for example).

I don't see any technical difficulty to spec and implement this (except
maybe how to avoid the horrible pop-up effect) and this covers everything.



If that happens the next step is to change our charter.

That is an administrative thing that takes a few weeks (largely to ensure
we get the IPR protection W3C standards can enjoy, which happens because
we spend the time to do the admin with legal processes) if there is some
broad-based support.


Unfortunately, despite of our efforts and patience, due to the lack of
agreement on this matter with the related W3C members, unless people
decide to restrict Intents to some trivial edit, share uses of simple
images, text, files, which looks quite limited (but surprisingly seems
enough for Microsoft, Mozilla and Google) and will necessarily end-up
redoing the spec again several years later, the specs will inevitably
cross again the path of the patent you know [4], for parts related to
the extraction mechanisms that time, which anyway the web will one day
implement.


[1]
https://lists.w3.org/Archives/Public/public-web-intents/2014Oct/0001.html
[2]
http://dev.mygrid.org.uk/blog/2014/10/you-want-to-do-what-theres-an-app-for-that/
[3] https://lists.w3.org/Archives/Public/public-web-intents/2015Feb/
[4] https://lists.w3.org/Archives/Public/public-webapps/2015AprJun/0911.html
[5]
https://lists.w3.org/Archives/Public/public-web-intents/2015Oct/.html

Making progress with items in Web Platform Re: App-to-App interaction APIs - one more time, with feeling

[Chaals McCathie Nevile]

On Sat, 17 Oct 2015 16:19:17 +0200, Anders Rundgren  
 wrote:



On 2015-10-16 18:00, Aymeric Vitte wrote:

Well, since I was on the list, I took the liberty of commenting a bit on  
this.


Please work on being more civil and constructive when you do. (Aymeric,  
that could apply to you to - and in fact the requirement to behave  
courteously is a general one for this list and others of the Web Platform  
WG).


Unless you work for a browser vendor or is generally "recognized" for  
some specialty, nothing seems to be of enough interest to even get

briefly evaluated.


I think you are misinterpreting your personal experience.

It is true that if you can demonstrate likely uptake on a broad scale, you  
will get a lot more enthusiasm than if you have an idea that you just  
think would help you. Browsers are among those who, by their nature, are  
more readily able to offer broad uptake. Major content producers likewise  
can do so, or those who make stuff that has a broad developer or user  
community involved.


An example of the latter are the developers of editing software. Most of  
those are very small, but they have a very large user community.  
Consequently, they have managed to engage the browser development  
community, and currently it seems that the discussions about rich-text  
editing in HTML, while complex and likely to take a long time, are very  
much worthwhile.


Meanwhile, even proposals I make as both a chair and the representative of  
a browser vendor (albeit a relatively unknown one outside Russia) stand or  
fall on the merits which include not only technical soundness but apparent  
likelihood of adoption on the Web.


Regarding App-to-App interaction I'm personally mainly into the  
Web-to-Native variant.


As I already pointed out to Daniel, this stuff is not in the current scope  
of the group, and you should work on it in the context of e.g. the Web  
Incubator Community Group, where it is relevant to their scope.


chaals, for the chairs.

Here the browser vendors have reportedly [1,2] decided to implement  
Google's
Native Messaging API "as is" without any discussions in related W3C  
forums,
something they will surely regret because it has a long list of  
shortcomings,

ranging from a difficult deployment scheme to limited functionality and
performance issues, not to mention a highly deficient security model:
https://lists.w3.org/Archives/Public/public-webappsec/2015Oct/0071.html

That the browsers vendors have gotten major push-backs after removing
their previous extension schemes (NPAPI, ActiveX) is obvious, but that
doesn't motivate rushing into crude workarounds:
http://www.cnet.com/news/google-paves-over-hole-left-by-chrome-plug-in-ban/

Anders

1] https://wiki.mozilla.org/WebExtensions#Additional_APIs
2]  
http://www.slashgear.com/project-spartan-is-now-edge-and-will-have-chrome-extensions-29381422/



Ccing the authors of [1], [2] and [3] if there is still an interest.



at this stage we don't have a deliverable for this work - i.e. the W3C
members haven't approved doing something like this in Web Platform  
working

group. Given that people repeatedly attempt to do it, I think the
conversation is worth having. Personally I think this is something the
Web needs


Indeed, that will be more than time to do so, but the current view of
the main actors or past specs seems a kind of narrowed and not very
imaginative/innovative, I don't think you should close the web intents
task force [5] but restart it on new bases.

This approach [1] and [2] looks quite good, simple and can cover all  
cases.


I don't know if we can call it a Web Component really for all cases but
let's call it as such.

In [2] examples the Bio component could be extracted to be passed to the
editor for example and/or could be shared on fb, and idem from fb be
edited, shared, etc

Or let's imagine that I am a 0 in web programming and even Web
Components are too complicate for me, I put an empty Google map and
edit/customize it via a Google map editor, there is [3] maybe too but
anyway the use cases are legions.

That's incredible that nobody can see this and that [1] did not get any
echo (this comment I especially dedicate it to some people that will
recognize themselves about some inappropriate comments, not to say more,
they made regarding the subject related to the last paragraph of this  
post).


The Intent service would then be a visible or a silent Web Component
discussing with the Intent client using postMessage.

Maybe the process could  be instanciated with something specific in href
(as suggested in [2] again) but an Intent object still looks mandatory.

But in case of visible Intent service, the pop-up style looks very ugly
and old, something should be modified so it seems to appear in the
calling page, then the Intent service needs to have the possibility to
become invisible (after login for example).

I don't see any technical difficulty to spec and 

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

[Chaals McCathie Nevile]

TL;DR: It's worth pursuing, but chat in WICG first to get a proposal that  
Web Platform WG will formally take up.


On Thu, 15 Oct 2015 19:26:11 +0200, Daniel Buchner
<dabuc...@microsoft.com> wrote:

After publishing the post, Google has reached out and we’ve been  
discussing options for solving this – would you like those discussions  
to be on the ML, or >back-channeled?




Hi Daniel,

at this stage we don't have a deliverable for this work - i.e. the W3C
members haven't approved doing something like this in Web Platform working
group. Given that people repeatedly attempt to do it, I think the
conversation is worth having. Personally I think this is something the Web  
needs, so one day we are going to have to get it done. On both counts, I  
encourage you to continue the conversations… But…


Since it is currently out of scope for this group, the normal path to get
it in scope would be to discuss it within the Web Incubator Community
Group. That way we don't lose important discussion by having it all
back-chanelled in private email.

That discussion should lead to a proposal for this group - use cases,
requirements, design considerations - initial thoughts about security,
privacy, internationalisation, accessibility, consistency with other Web
APIs, performance, …), perhaps a rough outline of a spec. You would be
aiming for First Public Working Draft, not Candidate Recommendation, so
having a pile of issues and bugs isn't a problem.

If that happens the next step is to change our charter.

That is an administrative thing that takes a few weeks (largely to ensure
we get the IPR protection W3C standards can enjoy, which happens because
we spend the time to do the admin with legal processes) if there is some
broad-based support. If we are at that point, the chairs and W3C staff
will handle most of the admin, beyond asking the Working Goup if they
agree we should add this to our charter.

And then we do the github magic to make a formal W3C Web Platform Working  
Group draft (usually takes me ages, so I'll ask someone smarter who will  
take a few minutes), and we're on our way to making a W3C standard…


…after that, it's just a matter of sorting out the issues, bugs,  
implementation, and then we're done :)


Until we look at the things we decided not to include in the first  
version, so we could ship faster…


cheers


- Daniel






From: Samsung account [mailto:bnw6...@gmail.com]


Sent: Thursday, October 15, 2015 9:26 AM

To: Arthur Barstow <art.bars...@gmail.com>

Cc: Daniel Buchner <dabuc...@microsoft.com>; public-webapps@w3.org

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








2015/10/15 下午11:58於 "Arthur Barstow" <art.bars...@gmail.com>寫道：






On 10/14/15 12:33 PM, Daniel Buchner wrote:











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,











Hi Daniel,






In case you haven't done so already, perhaps the Web Platform  
Incubation Group's Discourse service >would be a "better" place to  
discuss your proposal <http://discourse.wicg.io/>?







--



AB
















--
Charles McCathie Nevile - web standards - CTO Office, Yandex
   cha...@yandex-team.ru - - - Find more at http://yandex.com

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

[Aymeric Vitte]

Ccing the authors of [1], [2] and [3] if there is still an interest.

> 
> at this stage we don't have a deliverable for this work - i.e. the W3C
> members haven't approved doing something like this in Web Platform working
> group. Given that people repeatedly attempt to do it, I think the
> conversation is worth having. Personally I think this is something the
> Web needs

Indeed, that will be more than time to do so, but the current view of
the main actors or past specs seems a kind of narrowed and not very
imaginative/innovative, I don't think you should close the web intents
task force [5] but restart it on new bases.

This approach [1] and [2] looks quite good, simple and can cover all cases.

I don't know if we can call it a Web Component really for all cases but
let's call it as such.

In [2] examples the Bio component could be extracted to be passed to the
editor for example and/or could be shared on fb, and idem from fb be
edited, shared, etc

Or let's imagine that I am a 0 in web programming and even Web
Components are too complicate for me, I put an empty Google map and
edit/customize it via a Google map editor, there is [3] maybe too but
anyway the use cases are legions.

That's incredible that nobody can see this and that [1] did not get any
echo (this comment I especially dedicate it to some people that will
recognize themselves about some inappropriate comments, not to say more,
they made regarding the subject related to the last paragraph of this post).

The Intent service would then be a visible or a silent Web Component
discussing with the Intent client using postMessage.

Maybe the process could  be instanciated with something specific in href
(as suggested in [2] again) but an Intent object still looks mandatory.

But in case of visible Intent service, the pop-up style looks very ugly
and old, something should be modified so it seems to appear in the
calling page, then the Intent service needs to have the possibility to
become invisible (after login for example).

I don't see any technical difficulty to spec and implement this (except
maybe how to avoid the horrible pop-up effect) and this covers everything.


> If that happens the next step is to change our charter.
> 
> That is an administrative thing that takes a few weeks (largely to ensure
> we get the IPR protection W3C standards can enjoy, which happens because
> we spend the time to do the admin with legal processes) if there is some
> broad-based support.

Unfortunately, despite of our efforts and patience, due to the lack of
agreement on this matter with the related W3C members, unless people
decide to restrict Intents to some trivial edit, share uses of simple
images, text, files, which looks quite limited (but surprisingly seems
enough for Microsoft, Mozilla and Google) and will necessarily end-up
redoing the spec again several years later, the specs will inevitably
cross again the path of the patent you know [4], for parts related to
the extraction mechanisms that time, which anyway the web will one day
implement.


[1]
https://lists.w3.org/Archives/Public/public-web-intents/2014Oct/0001.html
[2]
http://dev.mygrid.org.uk/blog/2014/10/you-want-to-do-what-theres-an-app-for-that/
[3] https://lists.w3.org/Archives/Public/public-web-intents/2015Feb/
[4] https://lists.w3.org/Archives/Public/public-webapps/2015AprJun/0911.html
[5]
https://lists.w3.org/Archives/Public/public-web-intents/2015Oct/.html

-- 
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

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

[Arthur Barstow]

On 10/14/15 12:33 PM, Daniel Buchner wrote:


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,



Hi Daniel,

In case you haven't done so already, perhaps the Web Platform Incubation 
Group's Discourse service would be a "better" place to discuss your 
proposal ?


--
AB

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

[Daniel Buchner]

After publishing the post, Google has reached out and we’ve been discussing 
options for solving this – would you like those discussions to be on the ML, or 
back-channeled?

- Daniel

From: Samsung account [mailto:bnw6...@gmail.com]
Sent: Thursday, October 15, 2015 9:26 AM
To: Arthur Barstow <art.bars...@gmail.com>
Cc: Daniel Buchner <dabuc...@microsoft.com>; public-webapps@w3.org
Subject: Re: App-to-App interaction APIs - one more time, with feeling


2015/10/15 下午11:58於 "Arthur Barstow" 
<art.bars...@gmail.com<mailto:art.bars...@gmail.com>>寫道：
>
> On 10/14/15 12:33 PM, Daniel Buchner wrote:
>>
>>
>> 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=01%7c01%7cdabuchne%40microsoft.com%7cf6c3552c8f534236d50a08d2d57d5758%7c72f988bf86f141af91ab2d7cd011db47%7c1=lcuE8v13lcW8wpNqw4KUA4L2XP%2fJ4EfFqURrpJnME34%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,
>>
>
> Hi Daniel,
>
> In case you haven't done so already, perhaps the Web Platform Incubation 
> Group's Discourse service would be a "better" place to discuss your proposal 
> <http://discourse.wicg.io/<https://na01.safelinks.protection.outlook.com/?url=http%3a%2f%2fdiscourse.wicg.io%2f=01%7c01%7cdabuchne%40microsoft.com%7cf6c3552c8f534236d50a08d2d57d5758%7c72f988bf86f141af91ab2d7cd011db47%7c1=3hIRe8Wwv%2bPKVVdH5HTOSzzbC76UxH6JEWmP9csIO2U%3d>>?
>
> --
> AB
>
>