Re: Web Intents based APIs

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.****
>
>  ****
>
> ** **
>