- From: Anders Rundgren <anders.rundgren.net@gmail.com>
- Date: Sat, 17 Oct 2015 19:36:54 +0200
- To: Chaals McCathie Nevile <chaals@yandex-team.ru>, Aymeric Vitte <vitteaymeric@gmail.com>, Arthur Barstow <art.barstow@gmail.com>
- Cc: public-webapps@w3.org, ianwdunlop@gmail.com
On 2015-10-17 17:58, Chaals McCathie Nevile wrote: <snip> >> 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/0000.html >>> >> >> > >
Received on Saturday, 17 October 2015 17:37:28 UTC