RE: Web Intents based APIs

See inline, [Jungkee]

 

From: Greg Billock [mailto:gbillock@google.com] 
Sent: Saturday, June 02, 2012 2:33 AM
To: Nilsson, Claes1
Cc: public-web-intents@w3.org
Subject: Re: Web Intents based APIs

 

Return types are harder.

 

It'd be really nice to specify Blobs for binary MIME types and raw text
content for text MIME types as return values. There are a couple of thorny
problems with that at present, however. Blobs aren't transferable, and so
are not supported as return types. I think we will achieve a solution to
this, but not for a while. Looking at Android intents, they really favor URL
return types, and those are much more convenient in many cases than Blobs.
Additionally, we don't have any metadata construct for return types at
present.

 

[Jungkee] this is exactly what I have been pondered upon. The Gallery API
certainly needs a type to return "mediaObject" (and its array.)  Regarding
Blob vs URL, I tried both in the demo (though I sent the JSON stringified
object with metadata in fact.) The result is, with the service side hosted
on a public node server, the Blob approach does not seem to work well (even
only for dozens of hundred-KB-size images.) 

I think if we would take the Blob approach into account, we need to add a
way for the invocation side to asynchronously access the returned data in
the callback.

 

 

 

So I'm leaning towards this prescription for return types for MIME: the
service should strive to return the same type (url or text/blob) that it was
given. If it knows that won't work, or if it is too onerous, it can return a
url instead of the raw text/blob data. This puts a burden on the client to
check the return value's type to see if it is Blob/text or url. I don't
think that's too painful, but it is definitely a downside. In addition, we
should add the corresponding web messaging transferables array and extras to
the return type to match the invocation side. This'll help us out as Blobs
become better options, but URLs are so convenient (as can be seen by Android
usage), that they aren't expected to go away.

 

Any reactions or ideas? There's some good parts here, but there's a lot not
to like about this plan, so I'd be really happy to hear a better option!

 

 

On Fri, Jun 1, 2012 at 9:30 AM, KOMATSU Kensaku <kensaku.komatsu@gmail.com>
wrote:

Claes,

 

I like your idea considering the standardization process for specific
combinations. I also agree that to make

interoperability better your proposal will be helpful.

 

I want to clarify your idea. My opinion is that some combinations such as
Gallery or Contacts should

be standardized but everything should not be. I think there should be
sandbox spaces for some

Action and Types pair (and it should be documented in schema url). Anyway,
to list the candidates for

it is nice idea, I presume. It'll be helpful for developers who want to make
use of WebIntents.

 

 

Agreed. We won't nail down everything: the action and type namespaces will
remain open. But we definitely need to specify the common ones to promote
good ecosystem development, and clearly any API that rides over intents will
want to be well specified. My expectation is that such APIs will almost
always have custom literal type strings which are under their control and
can have their data specified.

 

 

On Fri, Jun 1, 2012 at 9:00 AM, Nilsson, Claes1
<Claes1.Nilsson@sonymobile.com> wrote:

Hi,

 

To achieve interoperability between Client applications and Service
applications Web Intents based APIs need to be specified. I assume that the
combination of Action and Type enables a specified API to be used for
interaction between Client and Service. So this has to be standardized.

 

It seems that this is an area where still a lot have to be done.  I have
only seen one tangible proposal for a Web Intents based API submitted to
W3C, that is the Gallery API,
https://dvcs.w3.org/hg/dap/raw-file/16185b62381d/gallery/index.html. Robin
has also posted thoughts on a Web Intents based Contacts API,
http://www.w3.org/wiki/WebIntents/ContactsAPI.

 

I wonder if people on this list know of more tangible proposals for Web
Intents based APIs than the two mentioned above? Which are your thoughts on
driving the standardization on Web Intents based API further?

 

This is essential in order to succeed with Web Intents.

 

Best regards

  Claes

 

 

cid:3333625383_1036728

Claes Nilsson M.Sc.E.E
Master Engineer, Research 
Technology Research - Advanced Application Lab

Sony Mobile Communications        
 Phone:  +46 10 80 15178 <tel:%2B46%2010%2080%2015178> 
Mobile: +46 705 56 68 78 <tel:%2B46%20705%2056%2068%2078> 
Switchboard: +46 10 80 00000 <tel:%2B46%2010%2080%2000000> 
E-Mail: mailto:claes1.nilsson@sonymobile.com
<mailto:claes1.nilsson@sonyericsson.com> 
Visiting Address; Nya Vattentornet 
SE-221 88 LUND,
Sweden 

Disclaimer:
The information in this e-mail is confidential and may be legally
privileged. It is intended solely for the named recipient(s) and access to
this e-mail by anyone else is unauthorized. The views are those of the
sender and not necessarily the views of Sony Ericsson and Sony Ericsson
accepts no responsibility or liability whatsoever or howsoever arising in
connection with this e-mail.Any attachment(s) to this message has been
checked for viruses, but please rely on your own virus checker and
procedures. If you contact us by e-mail, we will store your name and address
to facilitate communications. If you are not the intended recipient, please
inform the sender by replying this transmission and delete the e-mail and
any copies of it without disclosing it.