W3C home > Mailing lists > Public > public-web-intents@w3.org > August 2012

RE: Means for allowing triggering of all registered handlers

From: Josh Soref <jsoref@rim.com>
Date: Thu, 23 Aug 2012 14:50:27 +0000
To: WebIntents <public-web-intents@w3.org>
Message-ID: <957F1ECDA90E004B8DBDE23CFC94E3A33A518AED@XMB103ECNC.rim.net>
Brett Zamir wrote:
> Could a means be added to Web Intents to allow ALL matching registered
> handlers to be executed (with an event to indicate completion)?

I don't think this makes sense. The best version I can see for something like this is a page implementing the same handler type and having it ask as both a provider and a client.

In programming, we'd call it a Tee.

Your page can work just like an email client's add attachment page works:
When I click attachments, I get a [browse] button. When I click [browse] and select a file, the mail client adds another [browse] button. When I'm done, I click the [done/send] button in the page (which is just a normal button).

This is a trivial thing to implement, and actually a useful thing to implement, but it doesn't require an API change on the part of WebIntents.

Tees would fall under §11 Filter/Transform Actions of [1] Web Intents - Fourth Parties (part 5). 

I'll note that recently the Cordova group discovered that their naïve implementation of the old DAP Contacts API (pre Intents) had performance issues because they were sending requests to all local contacts providers. The odds of someone naïvely asking for "send to everyone" and of the user being confused by the request and the possibly negative consequences are quite high.

The mail-attachment UI I've described above is pretty easy to implement, and pretty easy for the user to understand, they'd even understand when they want to use it. If they want to aggregate say 3/17 "Gallery" providers, then they could use the Gallery Tee and then pick those three.

We've talked about encouraging UAs to persist mappings, and making Tees work better would be possible by persisting mappings. But I believe that even this persistence doesn't require spec changes, and if it does, there are non Tee use cases which can be used to facilitate any required spec changes.

[1] http://lists.w3.org/Archives/Public/public-web-intents/2011Nov/0038.html


---------------------------------------------------------------------
This transmission (including any attachments) may contain confidential information, privileged material (including material protected by the solicitor-client or other applicable privileges), or constitute non-public information. Any use of this information by anyone other than the intended recipient is prohibited. If you have received this transmission in error, please immediately reply to the sender and delete this information from your system. Use, dissemination, distribution, or reproduction of this transmission by unintended recipients is not authorized and may be unlawful.
Received on Thursday, 23 August 2012 14:50:58 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 20:14:47 UTC