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