W3C home > Mailing lists > Public > public-webapps@w3.org > October to December 2015

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

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
Message-ID: <56228736.7090301@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

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 18:14:58 UTC