Fwd: Nay vote, no Draft.

13 views
Skip to first unread message

Joe Gibbs Politz

unread,
May 29, 2012, 8:17:17 PM5/29/12
to belay-r...@googlegroups.com
Interesting critique of Web Intents, as the working draft proposal goes forward.


---------- Forwarded message ----------
From: rektide <rek...@voodoowarez.com>
Date: Tue, May 29, 2012 at 1:46 PM
Subject: Nay vote, no Draft.
To: public-we...@w3.org


Hi. I'm not sure whether I get a vote or not, I'm not a part of the
w3, so I think not, but
I am a nay in Web Intents going to Draft. Please be kind if I am out
of line in addressing
you all as such, and thank you for your kind consideration:

Section 1, sentance 1:

"Web Intents enable rich integration between web applications."

This is the core of web intents, yet web intents specifies no
protocol, no profiles for
protocols, to enable actual integration.  At presnt, Web Intents is a
client API only, with
no discussion as to how actual integration occurs below the UA layer.
To properly
'facilitate interchange' of 'services available on the web hav[ing] a
need to pass rich data
back and forth as they do their jobs,' this document must go beyond
describing the client-UA
interaction and must address what is really at stake.

What is really at stake is a form for UA's to interact with services.
Without words
describing how this integration is achieved, integration is impossible
and the goals
proposed in the introduction of Web Intents are unattainable.

Paragraph #3 of the introduction:

"The lifecycle of an Intent is that first, a client requests an Intent
be handled. This
Intent data is then passed to the User Agent, which allows the user to
select which of
potentially many possible services to use. Then the service is passed
the Intent data and is
provided a UI by the User Agent in which to perform the action
specified in the Intent.
Finally, the service may also return data as output back to the client."

This document describes:

1. A client request to handle an intent.
2. The Intent data being passed to the user agent
3. Mechanisms the UI should use to display possible services
4. The mechanism for the client receiving data back from the UA.

What is missing is the service being passed the intent data by the UA,
and the service
returning data to the UA. At present, this document is insufficient
for implementing a Web
Intent service, as it presents no standards for actually invoking
services. I vote nay until
a Web Intent service can be implemented to spec, and with respect I
beg all of you to
please make a stand and vote no on an integration spec for which
making services is not
documented.

Kind regards,
rektide / mf
Reply all
Reply to author
Forward
0 new messages