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

Hi Rich,

On Jan 24, 2012, at 12:35 , Rich Tibbett wrote:
> Robin Berjon wrote:
>> 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.

So you're limited to HTTP verbs. How do you capture the difference between view and pick? How do you capture edit? How do you capture new for that matter? More generally, how do you avoid overloading HTTP's semantics?

>> 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.

I don't understand what actions you're filtering on, HTTP verbs?

Is the idea that this would expose hosts of services that vaguely look like HTTP but e.g. only support one method, e.g. POST? I'm sorry but I've re-read this thread and I still don't see the value in the overhead involved in emulating some bits of HTTP without really quacking like it over using things like postMessage().

> 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).

That's already being discussed, but concerning the web+ scheme, it doesn't seem that the goal was to lead to scheme-minting proliferation — rather the point was to provide a security mechanism so that future schemes could whitelist themselves.

> 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].

This is an interesting example. See below.


> // 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>

Your server-side handlers filter what they accept based on media type. But where does this media type come from in the client invocation above? I don't know it until I've retrieved the content. So I have to at least HEAD the content before I know which handler to pick.

But wait, how do I even HEAD that content? I'm a regular UA, I don't handle web+storage so I can't really do that. All I know is that I have two services that know how to handle such URIs, so I'll ask them. Oh but wait, I need the media type. Do I ask *both* for the media type of the resource so that I can know which one to ask what to do with it? Does the user get asked twice (or n-times) due to the security and privacy implications?

Of course that's just the start of it. Reading between the lines I think you meant for "web+storage:example.com/myimage.png" to be somehow accessed over HTTP. But how do I know if it's HTTP or HTTPS? Do I try both? What if I get a different resource for each?

The way RPH works is that it gets a URI on which it can act, that's all. It can then fetch it using its own means. How does that happen above? What if that resource is one I have access to based on credentials specific to me (might be a cookie, might be a client certificate), are my credentials saved with a third-party service that could highjack them or do we expect them to fail in a manner that is inexplicable to the user? Is this assuming universal CORS?

What happens if the RPH handler uses different accept headers from those I used and ends up with a resource of a different type, that would normally cause *another* RPH handler to be invoked?

What's the fallback behaviour if my UA doesn't have a handler for web+storage?

> // Client-side invocation example 2:
> <form action="web+storage" method="POST">
>  <input type="file" name="image" accept="image/*"/>
> </form>

I assume you meant "web+storage:" there. Otherwise this has fewer holes than the above. Still, there's no clear fallback approach, unless I've missed something.

-- 
Robin Berjon - http://berjon.com/ - @robinberjon

Received on Tuesday, 24 January 2012 12:24:28 UTC