- From: Chaals McCathie Nevile <chaals@yandex-team.ru>
- Date: Sat, 17 Oct 2015 17:58:59 +0200
- To: "Aymeric Vitte" <vitteaymeric@gmail.com>, "Arthur Barstow" <art.barstow@gmail.com>, "Anders Rundgren" <anders.rundgren.net@gmail.com>
- Cc: public-webapps@w3.org, ianwdunlop@gmail.com
On Sat, 17 Oct 2015 16:19:17 +0200, Anders Rundgren <anders.rundgren.net@gmail.com> 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 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 >> > > -- Charles McCathie Nevile - web standards - CTO Office, Yandex chaals@yandex-team.ru - - - Find more at http://yandex.com
Received on Saturday, 17 October 2015 15:59:37 UTC