Web Wishes (was: Blog post for review)

Hi folks,

sorry for the interruption, a baby happened in the meantime :)

On 12/06/2013 18:08 , Marcos Caceres wrote:
> On Wednesday, June 12, 2013 at 4:54 PM, François REMY wrote:
>>> One brick that I would consider important in this is Web Intents
>>> (or whatever evolution thereof). It makes it possible to connect
>>> an arbitrary user-selected service to an application. It is
>>> useful in this context because a number of platform services can
>>> also be exposed as remote services. To take an example, an API to
>>> interact with a user's contacts could use an online service just
>>> as well as one provided by the browser to the local address book.
>>> This makes it possible to introduce services without browser
>>> support, but that can be enhanced by it when it comes.
>>>
>>> I'd like to rekindle the work that was done in that area but in
>>> an as trimmed-down as possible manner, possibly that can be
>>> (partially) polyfilled. I'm happy to discuss it here if ever
>>> there's interest.
>>
>> This is certainly of interest. I wonder if the API could not be
>> improved now that Futures are part of the platform.
>
> I don't think it was an API issue… more of a UX issue for users (at
> least, that's the word on the street).

I think that the UX issues stemmed a lot from the fact that the existing 
solution did maybe too much at once. In Intents, in order to edit an 
image you would do something like:

var intent = new Intent({ action: "EDIT",
                           type:   "image/jpeg",
                           data:   someBlob });
navigator.startActivity(intent, cb);

And that would directly go to UI (typically open a tab). The fact that 
it had default behaviour means that that default behaviour has to be 
good. It also means that for cases in which you want something different 
(e.g. embed the intent service), you need to add options to the API, and 
down that path lies all sorts of ugliness. Mozilla's Web Activities have 
a different API but with essentially the same approach.

I reckon that it might be best to decouple the step of obtaining a 
pointer to a service from its UI as much as possible. So instead of the 
above, one might have something like:

var wish = new Wish({ action: "EDIT", type: "image/jpeg" });

What you get back is an object that has a field which is a magic opaque 
URL (like Blob URLs) that you can assign anywhere that makes sense in 
your UI:

   • iframe.src = wish.src
   • window.open(wish.src)
   • navigator.lauchURL(wish.src) (see 
https://www.w3.org/Bugs/Public/show_bug.cgi?id=20799)
   • ...

Loading that URL can display a service picker for the user (the calling 
page gets no event from that), and only once the service is picked and 
loaded do you get a load event. Then you just communicate with 
postMessage().

This of course still leaves clickjacking attacks open. But no more than 
what is possible using existing services. We could possibly think of 
ways of mitigating that, too.

Thoughts?

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

Received on Monday, 1 July 2013 09:35:15 UTC