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

On the subject of FileSaver, specifically window.saveAs, I have demos that
show use of "http://webintents.org/save" intent which fits work very well
and it would be up to the UA to decide if they want to offer an interface
for access to the local fileSystem.  So it could either be a cloud or local
FS that the user chooses.



On Sun, Nov 13, 2011 at 11:18 PM, Paul Kinlan <paulkinlan@google.com> wrote:

> Hi,
>
> CIL
>
> On Sun, Nov 13, 2011 at 10:35 PM, Charles Pritchard <chuck@jumis.com>wrote:
>
>> **
>> On 11/10/11 3:10 PM, Greg Billock wrote:
>>
>>
>>
>> On Thu, Nov 10, 2011 at 8:15 AM, Rich Tibbett <richt@opera.com> wrote:
>>
>>> Dominique Hazael-Massieux wrote:
>>>
>>>> Le jeudi 10 novembre 2011 à 16:27 +0100, Rich Tibbett a écrit :
>>>>
>>>>> Hi
>>>>> a.) to register a URL endpoint as an intent provider the user must
>>>>> visit
>>>>> a web page (presumably hosted by the target device itself) and capture
>>>>> the intent registration from that page before that intent provider can
>>>>> be used within the UA.
>>>>>
>>>>
>>>> My understanding is that this is not a MUST at all, but the way
>>>> Web-based services can be added by a user.
>>>>
>>>
>>  Yes. The API as currently proposed has a way for web apps to register
>> services, but it is not intended to limit the ability of the user agent to
>> register services by other methods. If you look at our Chromium commits,
>> we're experimenting with ways to register services through installation of
>> web apps, for instance. Registering handlers through local network
>> discovery or interaction with the host OS also seems like a promising
>> direction.
>>
>>
>> Has there been further movement toward the existing register*Handler APIs:
>>
>> http://www.whatwg.org/specs/web-apps/current-work/multipage/timers.html#custom-handlers
>>
>> I've practiced with those methods and from a usability perspective, I'm
>> starting to think those html5 methods are not going to be worth using.
>> Whatever the end-case, Web Intents seems to be where the UI is going to
>> evolve.
>>
>> I understand that from the Chromium-OS side, Web Intents is likely to
>> take over the fileHandlers permission.
>> That tells me that registerContentHandler is not going to happen.
>>
>
> The intent model can support "view" with the associated MIME-type which is
> what regsiterContentHandler does.  The point we need to discuss is
> registerContentHandler will implicitly start when a file is loaded with
> that mime-type, so should a UA initiate "startActivity" implicitly with a
> "view", the detected mime type and the file data?
>
>
>>
>> Chromium-OS is headed from a vendor-specific extension into web intents:
>> http://code.google.com/chrome/extensions/fileBrowserHandler.html
>>
>> I'm OK with that. I want to make sure we're all aware of the divergence.
>>
>
> I am currently tracking this.
>
>
>>
>>
>>
>>   I think the Web-page-in-a-separate tab is also an optional aspect of
>>>> Web
>>>> intents; the browser could serve as a broker between the local-network
>>>> service and the Web page.
>>>>
>>>
>>>  This is unclear but I hope we end up with something that provides
>>> non-tabbed (direct) interaction also. In some cases it may be superfluous
>>> to have a separate window open that denotes the service endpoint.
>>
>>
>>
>>  The proposal we're working from uses "disposition=inline" to denote
>> this -- that is, services can be placed within the visual context of the
>> calling page. Our prototype uses an expansion of the service picker dialog
>> to host that service page.
>>
>>
>>
>> It seems like the anchor download attribute fills another need. Should
>> these proposals be wrapped up into an omnibus package?
>> In my opinion, they're an extension to the very-old "target" attribute.
>>
>> In the new Web Apps world, we're targeting FileSaver and iframe sandbox.
>>
>>
>>> Thanks for the quick reply and good to ensure this stuff gets captured
>>> in the TF charter.
>>>
>>> As Chaals said, let's get going on this. The concept of Web Intents is
>>> great and we're not married to any particular proposal at this point. We
>>> can see if it works for our UCs when the task force kicks off.
>>>
>>>
>>
>>  Clarke Stevens asked about a discovery mechanism whereby a client page
>> discovers a set of local network devices which is then updated by an event
>> driven mechanism. As currently sketched out, there's room in our web
>> intents proposal for the return of a MessagePort for persistent
>> communication. The proposal doesn't focus on that problem, though. It is
>> aimed more at an RPC-style request/response interaction paradigm. Web
>> Intents, the way we're currently thinking about it, has a lot to do with
>> user consent to the connection between the applications. When there's a
>> persistent connection, that consent model starts to break down. That said,
>> there are definitely use cases for which establishing a persistent
>> connection is appropriate. I'm eager to discuss how to best handle those
>> cases as the TF starts up. I think that'll be a key focus of refinement.
>>
>>
>> Hixie made a good point when he asked us to review Web Messaging. Intents
>> as it's implemented by Google -- and it's already happening -- Google
>> started this push awhile ago and I get the impression that Paul Kinlan has
>> high level support -- intents as it's implemented is built upon Web
>> Messaging and postMessage dynamics.
>>
>> postMessage has MessagePort and Transferable arrays (thank goodness). I
>> believe those semantics already solve issues of RPC, bi-di and zero-copy.
>> They've had years of work put into them to get to this place of consensus.
>>
>> timeless brought up some excellent corner cases that I hope are discussed
>> soon in the upcoming TF mailing list. That stated, I think building Intents
>> atop postMessage is the right move. Web Messaging has already solved many
>> of the difficult problems.
>>
>
> They have also introduced a lot of problems.  The RPC style isn't easily
> supported over MessageChannel and from the developer side of the things the
> less they have to do the less chance there is for error (i.e, removing the
> need to close channels, removing the need to know if the response should be
> 1 or n responses) and the higher likelihood of adoption. All being said,
> there will be a class of applications where that channel based
> communication with it's own protocols will be needed and we should discuss
> that (it was something we have talked about by passing a message port as
> the data with the intent), but the model we have now feels very good when
> developing against it.
>
>
>> As far as I can tell, Web Intents adds another high level semantic: the
>> "Intent" semantic. I've proposed previously that intents could work over
>> HTTP in addition to the browser and OS interoperability, simply by adding a
>> "Web-Intent(s):" header onto Web Sockets and HTTP RPC requests.
>>
>
> It is interesting, some of the applications I have built have had to read
> the state in JS and then send the data to the server via XHR, removing this
> step would ease the pain for developers and can make it a more seamless
> experience for the user. It is something we should discuss further IMO.
>
>
>>
>> A Web-Intent may have a mime-type, it'll have some kind of message body,
>> perhaps some arguments -- the one thing it adds onto existing semantics is
>> yet-another text field describing the intent. That extra dimension of
>> information seems sufficient to handle many use cases -- yet to be
>> discussed on the Web Intents TF list.
>>
>
> Can't wait.
>
>
>>
>>
>> -Charles
>>
>>
>
>
> --
> Paul Kinlan
> Developer Advocate @ Google for Chrome and HTML5
> G+: http://plus.ly/paul.kinlan
> t: +447730517944
> tw: @Paul_Kinlan
> LinkedIn: http://uk.linkedin.com/in/paulkinlan
> Blog: http://paul.kinlan.me
> Skype: paul.kinlan
>
>


-- 
Paul Kinlan
Developer Advocate @ Google for Chrome and HTML5
G+: http://plus.ly/paul.kinlan
t: +447730517944
tw: @Paul_Kinlan
LinkedIn: http://uk.linkedin.com/in/paulkinlan
Blog: http://paul.kinlan.me
Skype: paul.kinlan