Re: Web Intents based APIs

On Mon, Jun 4, 2012 at 1:25 AM, Nilsson, Claes1 <
Claes1.Nilsson@sonymobile.com> wrote:

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


The MIME types are really nice in that they're conceptually very simple and
lightweight -- that makes them great for interchange, because they have a
minimum of structure. When APIs are fine with that, there's no reason not
to use them. For many, though, the type probably wants to have more
structure to it, which MIME types simply don't provide. For instance, the
Gallery API type may want to provide an object which allows you to read
through it to open different images asynchronously. MIME types won't
support that kind of interaction. They're definitely simpler, but sometimes
that's a limitation and not a feature.



> **
>
> 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> 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 ? J****
>
>  ****
>
> Best regards****
>
>   Claes****
>
>  ****
>
> *From:* James Hawkins [mailto:jhawkins@google.com]
> *Sent:* den 2 juni 2012 03:33
> *To:* Greg Billock
> *Cc:* Nilsson, Claes1; 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.****
>
>  ****
>
> 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.****
>
>  ****
>
>  ****
>
>  ****
>
>  ****
>
> ** **
>

Received on Monday, 4 June 2012 16:47:45 UTC