- From: Greg Billock <gbillock@google.com>
- Date: Thu, 1 Dec 2011 13:46:51 -0800
- To: public-web-intents@w3.org
On Tue, Nov 22, 2011 at 3:22 PM, timeless <timeless@gmail.com> wrote: > Web Intents - Fourth Parties (part 5) > > There are three main parties involved in the Actions I've described: > 1. The User Agent / User > 2. The Client / Page requesting an Action > 3. The Partner / Provider that will respond to the Action > > I'd like to suggest possible Fourth parties for a moment: > §11 Filter/Transform Actions > §12 Reputation Providers > > §11 Filter/Transform Actions > > I think we're going to want to encourage vendors to produce and offer > Filter/Transform Actions. > > To use my Printing examples, anything that offers Print to File is a > Transform from <Print> to <Save>*. These can be used to address > certain problems. Note that while some of these appear to just be > Previewing tools (ala §7), most actually allow Editing (highlighting, > rotation, re-sequencing, cutting, saving, etc.). This is something we've given a little thought to, but without much definite to say about it. I want to make sure we don't end up specifying a generic graph construction language which implementors will find daunting to use. The sweet spot is for compositing functionality (which may be quite complex!) into web apps, and I want to make sure that simple case is kept simple. As to whether intents can be chained, or understood as filter or transform operations, my current thinking is that this kind of behavior is best left to either the client page, where particular workflows can be facilitated. (One demo Paul Kinlan has made uses this kind of thing in the imagemator [1].) Or to the service, which may want to allow editing of an image during pick, for instance, or to side-save an image being edited. In other words, the web apps themselves may be able to use intents in more complex ways, but the users of those apps wouldn't be responsible for hooking them up in this way. (Of course, it is possible to imagine a complex extension providing scripted intent-driven composition to handle different workflows. That'd be awesome, and would be aimed at the people using tools like Pipes [2] or IFTTT [3].) > §12 Reputation Providers > > Clients/Providers will often be dealing with confidential + valuable > data.As such, users could probably benefit from unaffiliated > reputation providers who can review both Client Pages and Provider > Partners. This, in my opinion, isn't really part of the intents API or spec itself, but is instead part of the more generic problem of assigning rankings to web apps, which includes security analysis, usability, fitness to purpose, features comparison, etc. I don't think the spec should be directly addressing things like this. [1] http://www.imagemator.com/ [2] http://pipes.yahoo.com/pipes/ [3] http://ifttt.com/
Received on Thursday, 1 December 2011 21:47:22 UTC