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.

Thanks,
James

On Fri, Jun 1, 2012 at 10:32 AM, Greg Billock <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
> > 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****
>>
>> ** **
>>
>> ** **
>>
>> [image: 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
>> Mobile: +46 705 56 68 78
>> Switchboard: +46 10 80 00000
>> E-Mail:* **mailto:claes1.nilsson@sonymobile.com<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.****
>>
>>  ****
>>
>> ** **
>>
>
>