On 11/13/11 3:18 PM, Paul Kinlan wrote:
On Sun, Nov 13, 2011 at 10:35 PM, Charles Pritchard <ch...@jumis.com
<mailto:ch...@jumis.com>> wrote:
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.
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?
Seems like the UA gets to make all of the decisions here.
I think the disposition=inline vs. [a download] really sets up the
intent well. If the anchor is marked for inline, it makes a lot of sense
that the UA would check on its registered intents for handling it
implicitly. There's no reason to push authors into triggering intents
when the user can setup those preferences on their own.
PDF is a good model for this one... it's a "view" situation and it's
likely to have only one viewer, and it's also likely to be viewed
inline. Mozilla's work on PDF.js is certainly showing the power of web
app registration for this complex file format. I know if I register
pdf.js as my PDF viewer, that's what I want to pop up. I also know that,
if I'm running Chrome, I want, somewhere, the option of switching
between the Foxit and Mozilla viewers.
I'm not really happy with the Chrome interface for adding and removing
registered protocol handlers. It's so buried, nobody is going to know
about it. Web Intents really fills that gap of "Open With..." and
context menus. I find the existing context-menu solution distasteful: a
background page just so I can register a link? ugh!#$.
Does anybody use registerProtocolHandler in any real sense? Is
registerContentHandler needed? It seems like Web Intents is an evolution
on the concept. I don't think we're going to see convergence on those
old methods. I'm ready to leave them both in favor of a yet-to-be
announced candidate (web intents).
URIs are better than protocols, and Intents are better than content
handlers. In my opinion.
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, the model doesn't prohibit, nor does it encourage,
the passing of MessageChannel.
It's very much made for an RPC style of communication, but if the
message being passed back is a channel, well that's just fine.
Am I mistaken? What I'm seeing is that we get MessageChannel for free,
and there's no need to specify further.
Individual Intent authors can do that themselves.
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.
Even the MessageChannel concept can work over Web Sockets. So can
postMessage ( ArrayBuffer ) -- once the server has received the
ArrayBuffer, the client can clear it from RAM.
As developers, we can often make things seamless for the user. The thing
is, I think it can be fairly seamless for the developer as well.
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.
Well, if it's this easy, then I guess I'll find something more difficult
to discuss ;-)
Onward to "discovery" intents.
-Charles
