Re: Transferable Objects, was: Re: Web Messaging Intents, was: Re: [DRAFT] Web Intents Task Force Charter

On Tue, Nov 22, 2011 at 10:32 AM, Rich Tibbett <richt@opera.com> wrote:
> However, another intent could allow subsequent messaging via a channel after
> an initial exchange of data. We should explore real use cases for that. For
> example, a user invokes a 'http://foo.com/editimage' intent action with some
> initial image data and then their web app can apply real-time filters to the
> image via the provided messaging channel - as long as
> http://foo.com/editimage is defined to work with a messaging channel in the
> first place).

So, i'd kind of like to toy with a model where an intent consumer can
provide an Intent as its way to receive data back.

Using your example, if I want to let a user <ProcessImage>, then what I do is:

1. create an intent for process-image <self-reference>
2. create an intent for process-image <>, including the image data and {1}
3. dispatch {2}

4. The user's selected process-image intent gets the image data (and
the user agent holds the {1} intent)
5. When the user is done, the user clicks a Save button
6. That page creates an intent for process-image, including the new image data
7. dispatch {6}

8. The user agent knows that it has a process-image intent available
{1}, and it knows that the new intent that was dispatched {6} is a
process-image, so when it asks the user what intent to use, it
prefills {1} as the default (only for this specific instance, it
doesn't override the user's default process-image provider).
9. The user either chooses to <Continue> or selects another
process-image provider.

On the default path, you're just passing things around normally. But
with this approach, if the user wants to instead pass the image
through a chain of image filters, the user can.

Received on Tuesday, 22 November 2011 22:37:11 UTC