- From: Robin Berjon <robin@berjon.com>
- Date: Mon, 23 Jan 2012 14:38:58 +0100
- To: Paul Kinlan <paulkinlan@google.com>
- Cc: Rich Tibbett <richt@opera.com>, public-web-intents@w3.org
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. 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. 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). > I just don't think the two should be conflated. +1 -- Robin Berjon - http://berjon.com/ - @robinberjon
Received on Monday, 23 January 2012 13:39:24 UTC