W3C home > Mailing lists > Public > public-device-apis@w3.org > January 2011

Re: Messaging API usage (was: Agenda - Distributed Meeting 2011-01-12)

From: Dominique Hazael-Massieux <dom@w3.org>
Date: Wed, 12 Jan 2011 14:10:18 +0100
To: Rich Tibbett <rich.tibbett@gmail.com>
Cc: Frederick.Hirsch@nokia.com, public-device-apis@w3.org
Message-ID: <1294837818.21751.33.camel@altostratustier>
Le mercredi 12 janvier 2011 à 13:21 +0100, Rich Tibbett a écrit :

>         That said, I still think we should publish the existing
>         editors draft as
>         an updated draft of the document, given how we've vastly
>         reduced the
>          scope since the previous draft we published during the
>         summer.
> 
> 
> I'm questioning the much bigger issue of the rational for this
> specification in the first place, not about milestones on the
> specification's roadmap. 

Right, but better defining the scope is an important piece of explaining
the rational of the spec. Since we already have a document as a FPWD out
there, showing that we don't actually intend to spec everything that was
put in that first draft seems like an important message.
 
> On the 'saner way to compose body of messages' are you saying that URL
> Encoding a body string is the problem with URI schemes?

There is URL encoding (on top of the character encoding questions), URL
size limitations, the difficulty of manipulating URLs in JavaScript in
general (although I understand this is being addressed).

> Attachments provide a better use case but why, for example, could we
> not extend existing technologies - why could we not pass Blob URIs
> pointing to attachment files in the URI schemes instead? 

I'm not sure what you have in mind there; this might be the way to
address what I suggested above (tying the API more closely with URI
schemes), but it's hard to assess without a clearer example of what
you're envisioning.
 
I've also remembered another (small) advantage of the API: the developer
gets a notification of whether the message was successfully sent or not
(and for what reason if not).

> The user experience you mention didn't jump out at me on reading.

Hmm... Re-reading the security considerations, they don't make that very
clear indeed.

>  Perhaps either the Abstract or Scope could clarify exactly what is
> covered, what the intended user experience is (informative would be
> fine) and how it works with either a local device or web service. The
> spec should also highlight the benefits of the API over existing
> methods (i.e. URI schemes) and why this stuff could not be integrated
> with these existing methods.

Sounds good to me.

I would still be OK with moving ahead with publishing, but maybe it
makes more sense to make another editing pass if the scope of the work
still needs clarification even for a group insider :)

Dom
Received on Wednesday, 12 January 2011 13:10:31 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Wednesday, 9 May 2012 00:14:16 GMT