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

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/0000.html
>

Received on Saturday, 17 October 2015 14:19:49 UTC