RE: Web Intents based APIs

Hi Greg,

You state: "I wouldn't expect APIs built on web intents to use MIME type specifiers. They're worth some trouble to figure out because they have great interaction potential with existing systems, but by and large they end up requiring a lot of clients and services that more purpose-built types won't."

As my native language is not English I may have a language problem here as I don't understand your message.  You are elaborating on passing MIME type data through Web Intents at http://www.w3.org/wiki/WebIntents/MIME_Types. Do you think that we should withdraw this and only rely on schema.org types?

Best regards
  Claes

From: Greg Billock [mailto:gbillock@google.com]
Sent: den 4 juni 2012 04:24
To: Nilsson, Claes1
Cc: James Hawkins; public-web-intents@w3.org
Subject: Re: Web Intents based APIs


On Sun, Jun 3, 2012 at 8:27 AM, Nilsson, Claes1 <Claes1.Nilsson@sonymobile.com<mailto:Claes1.Nilsson@sonymobile.com>> wrote:
Hi James and Greg,

My assumption is that we need to do both. Isn't the first step to define what Greg is looking at on  http://www.w3.org/wiki/WebIntents/MIME_Types/ http://www.w3.org/wiki/WebIntents/schema.org_Types and the 2nd step to standardize tangible APIs such as https://dvcs.w3.org/hg/dap/raw-file/16185b62381d/gallery/index.html?

If we take the Web Intents based Gallery API proposal as an example this proposal states an API for Action "http://webintents.org/pick" and image, audio and video MIME types and will include for example a syntax for a filter parameter within the Intent "extras" attribute. If this API becomes a standard then the assumption is that Web Intents Clients and Services must assume the Gallery API syntax for the combination of Action =  http://webintents.org/pick and Type = "image/*", "audio/*" or "video/*". Correct?


I wouldn't expect APIs built on web intents to use MIME type specifiers. They're worth some trouble to figure out because they have great interaction potential with existing systems, but by and large they end up requiring a lot of clients and services that more purpose-built types won't.



So I assume that this must be standardized within W3C because:

* The API/protocol to use between Client and Service for combinations of Action and Type must be clarified.

* We should create Web Intents based new APIs (possibly based on existing APIs). This is relevant when we want to benefit from the Service Discovery feature provided by Web Intents, e.g. for Gallery and Contacts.

Correct or do I have got everything wrong ? :)

Best regards
  Claes

From: James Hawkins [mailto:jhawkins@google.com<mailto:jhawkins@google.com>]
Sent: den 2 juni 2012 03:33
To: Greg Billock
Cc: Nilsson, Claes1; public-web-intents@w3.org<mailto:public-web-intents@w3.org>
Subject: Re: Web Intents based APIs

Claes, can you clarify the intent of your message?  I read this as a call to document the process by which DAP (or other WGs) create new APIs based on Web Intents, e.g. Contacts API.  I think Paul and Greg are reading this as a call to have a formal process to standardize the Web Intents 'APIs', i.e. the standard actions provided by webintents.org<http://webintents.org>.

Thanks,
James

On Fri, Jun 1, 2012 at 10:32 AM, Greg Billock <gbillock@google.com<mailto:gbillock@google.com>> wrote:
This is a critical area, I agree. I've begun work on that in the web intents wiki, under the "Documentation for Web Intents Actions and Types" heading (see [1] and [2]).

[1] http://www.w3.org/wiki/WebIntents/MIME_Types
[2] http://www.w3.org/wiki/WebIntents/schema.org_Types

What I'd like to see is careful thought applied to the messaging formats, especially for MIME types. I think that literal types will end up being easier to define -- after all, you can just say exactly what all the fields are, what to expect, which are required and which optional, etc. MIME types are much better for interoperability, as they are generic, but that means they'll end up needing to be more generically defined.

Here's the state of my thinking on the issue right now. For passing data into the service, Blobs work great for binary data and plain text for textual types. There are extras to carry along any metadata required by the particular action that isn't contained in the raw content itself.

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.

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<mailto: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<mailto: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:image001.gif@01CD4239.92180830]

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.