Re: Is there an existing mechanism that can be used for WebIntents?

Hi Robin,

Thanks for the feedback. My comments are in-line below.

Robin Berjon wrote:
> On Jan 20, 2012, at 22:58 , Paul Kinlan wrote:
>>>> I would keep protocol handler just handling what it handles now.  It
>>>> has the ability to open up a window (letting it work in an iframe
>>>> seems a world of pain for security).  The reason why I say this is
>>>> that protocols (really they are schemes) such as cal, tel, http,
>>>> mailto are pointers to an external resource encoded - i.e, this uri
>>>> points to a calendar entry.  I would not want to conflate the protocol
>>>> and the action of "edit", "pick" for example with the protocol API.
>>>>
>>> I don't understand what you mean here. I think point towards a resource with
>>> a unique, structured identifier gives us an equivalent model without the
>>> mess of having to manage action verbs.
>> Verbs are the important thing here, you say what your application can
>> do - with RPH if you say you support "tel" that doesn't mean anything
>> other than you can handle the "tel" scheme.
>
> I very much agree with Paul here. For all that the URI/URL distinction has confused generations of web hackers the concepts that underlie it are still valid and useful. Naming something is very different from declaring what you can do to it.
>
> With WI you have a type of object (e.g. contacts) and actions you can perform on it (e.g. save, pick, edit, delete). Architecturally this is rather similar to how the Web is designed. If I understand Rich's RPH.next proposal, we'd replace that with web+contactssave, web+contactspick, web+contactsedit, web+contactsdelete and so on (or did I miss something?). That seems quite different from the Web's architecture as it stands; it would be more like having httpget, httppost, httpput, httpdelete, etc. depending on the expected action.

Actually the proposal allows you to just define web+contacts and then 
HTTP PUT, POST, GET, DELETE against it. Separating the actions in to 
their own 'protocols' would be entirely possible but probably wouldn't 
be best practice.

>
> Conversely, we could just have web+contacts but that loses us one of the core feature of WI which is the ability to pick which services can actually carry out a given action on a given type of object. Either the user would get to choose between services, some of which may not be able to carry out a given action, or we'd need to add support for some equivalent to OPTIONS — which strikes me as a bad idea as well.

We would add an options parameters to the registerProtocolHandler API 
that allows a web page to pre-filter requests from client pages. The 
options parameter would enable the UA to filter custom protocol actions 
and the proxying of that action by content type, HTTP method type, etc.

>
> Again, I may have missed something, but reusing RPH for this strikes me as excessive reuse, and cramming action information into identifiers is, I believe, a very bad architectural choice (incidentally it also seems to go against http://www.w3.org/TR/webarch/#URI-scheme).

Considering that a Web Intents shim has been created that essentially 
bootstraps against similar mechanisms that apply in this RPH.next 
proposal I'd be inclined to suggest we could build Web Intents on top of 
RPH.next...or even RPH.now for that matter.

One clear benefit of bootstapping Web Intents off the RPH mechanism is 
the ability to launch actions without JavaScript from e.g. an in-page 
DOM element, e.g. uploading an image to a compatible service endpoint 
[example].

Regarding http://www.w3.org/TR/webarch/#URI-scheme are you citing the 
reuse guideline as the problem? We're getting custom protocols via 
RPH.now any way so if you see conflicts it should be taken to the 
relevant mailing list (WHATWG and/or W3C HTML).

br/ Rich


[example]


// Server-side registration 1:

navigator.registerProtocolHandler(
  'web+storage',
  'http://istockphoto.com/lightbox/remote/loader',
  'iStockphoto Lightbox',
  {
    accepts: ['GET', 'POST'],
    types: ['image/*']
  }
);


// Server-side registration 2:

navigator.registerProtocolHandler(
  'web+storage',
  'http://xiph.org/user/store',
  'Ogg Video Store',
  {
    accepts: ['POST'],
    types: ['multipart/form-data', 'video/ogg']
  }
);


// Client-side invocation example 1:

<a href="web+storage:example.com/myimage.png">
   Add this image to another account
</a>

// Browser determines the content type and show registration 1 but not 
// 2 to the user to select. On selection, browser proxies the
// invocation as a HTTP GET to the selected handler.


// Client-side invocation example 2:

<form action="web+storage" method="POST">
   <input type="file" name="image" accept="image/*"/>
</form>

// Browser determines the content type and show registration 2 but not 
// 1 to the user to select. On selection, browser proxies the
// invocation to the selected handler.



[/example]

Received on Tuesday, 24 January 2012 11:36:29 UTC