Re: Means for allowing triggering of all registered handlers

Hi,

On 8/23/2012 9:20 PM, Paul Kinlan wrote:
>
> We have always tried to stay away from this, of seemed like a ux 
> nightmare and at the time only suited to applications that share 
> content. (If you have other use cases please let us know)
>
If you mean because of the excessive amount of data which could come 
through or because the user did not actually want all services shared, I 
would think browsers could allow management, even with per site 
preferences, by some drag-and-drop or select boxes, so they could 
specify services which could be excluded. The UA might even have a 
dialog which appeared every time the services were requested (with the 
ability to click a checkbox to turn it off), asking for the services to 
utilize within a given browser session. I think user experience will 
depend on the site; it could be used to implement the like of POP 
accounts, I think that is pretty powerful.
>
> The way we would suggest solving it is for apps like Hootsuite etc to 
> manage this as they already broadcast to multiple networks.
>

While this might work for some cases, I'm afraid it adds a bit of a 
barrier to entry and ties us more to 3rd parties rather than giving us 
direct access to our own data.

Thanks!
Brett

> On 22 Aug 2012 19:32, "Brett Zamir" <brettz9@yahoo.com 
> <mailto:brettz9@yahoo.com>> wrote:
>
>     Hi,
>
>     Could a means be added to Web Intents to allow ALL matching
>     registered handlers to be executed (with an event to indicate
>     completion)?
>
>     I would think one should be able to use such a means to make one's
>     application extensible via "plug-ins" whose code could add
>     overlays or behaviors (e.g., to allow 3rd parties to add their own
>     context menus to one's web app), of course bearing in mind
>     security concerns (as with single service usage), or the approach
>     could be used for publish-subscribe, etc.
>
>     For example, one might have a third party client app to request
>     Twitter, Facebook, Google Mail, etc. (e.g., if the user had set
>     such a preference to allow this behavior at these sites), to pass
>     on messages which could be shown and handled in a common interface
>     (like POP or IMAP email).
>
>     The "persistent connections" approach
>     (http://dvcs.w3.org/hg/web-intents/raw-file/tip/spec/Overview.html#persistent-connections
>     ) could also enable development of a multi-service chatting
>     application with discovery of new services.
>
>     Thanks,
>     Brett
>