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

Hi,

  I understand the issues about the abstract and the security chapters. I will try to provide an update on that asap.

  With regards to the scope and design of the API, the current approach was agreed in the last F2F. I would be happy to hear concrete proposals and implement them if they have wide group support. Anyway, this can be done after publishing a new draft.

Best regards


On Jan 12, 2011, at 2:10 PM, Dominique Hazael-Massieux wrote:

> 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 15:10:41 UTC