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

Rich Tibbett wrote:
> 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.

For the sake of argument, you could also content handler 1 like this:

var xhr = new XMLHttpRequest();
xhr.open('POST', 'web+storage', true);
xhr.setRequestHeader('Content-Type', 'image/png');
xhr.send( pngData );

or, Web Intents style, like this:

var handler = window.open('web+storage');
handler.onmessage = function( msg ) {
   if(source !== msg.source) return;
   if(msg.data = 'ready') {
     msg.source.postMessage({type: 'image/png'}, origin, pngData);
   }
}

(In this last example, a Web Intents style API could be provided to 
bootstrap the current Web Intents API on top of RPH.now as per the 
current shim)

>
>
> // 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:58:07 UTC