On 11/10/11 3:10 PM, Greg Billock wrote:
On Thu, Nov 10, 2011 at 8:15 AM, Rich Tibbett <ri...@opera.com
<mailto:ri...@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.
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 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.
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.
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.
-Charles
