Re: Messaging API Update

Le lundi 13 décembre 2010 à 16:10 +0100, María Ángeles Oteo a écrit :
> > A few comments:
> > * I don't think the "folder" property should be included in the *Message
> > interfaces, since it's not clear it would serve any useful purpose in
> > the "send" use case; if we need it for other operations, we should add
> > it then
> 
> The idea was that after executing the send() method, the folder
> attribute was updated. It might provide info about the folder in which
> the message is stored after the send method is invoked, depending on
> the sending operation result. For instance, when sending fails, the
> implementation may store a copy in the drafts folder.

But if we really want the folders attribute to reflect such a behavior,
we need to specify it; if we leave it undefined, nobody can actually
rely on it, making it more or less pointless. So I would still argue we
should remove it until we actually define how it is handled (which I
think we probably don't need in the first version of the API).

> > * I'm not clear whether we need the id property either; is there any use
> > case you have in mind for it?
> 
> Similarly, id should be also updated after invoking send(). This would
> allow to look for the messages that have been set through the future
> "Message Reading API".

Unless it is useful for developers in the specific scope of this API, I
suggest this should be specified in the Message Reading API when it is
developed.

> > * the timestamp property should be only about "sent" time, and should
> > probably renamed to sent_time? It might also benefit from being turned
> > into a TZDate once we have a spec for that
> 
> We kept the old name (timestamp) because I believed the same Message
> Interface could be reused in other messaging APIs. I.e. timestamp
> could be the sent time for sent messages and the received time for
> received messages.

I think the semantics of sent/received are sufficiently different that
they ought to be handled by different attributes; and again, I suggest
we focus only on the current API.

> > * accountId in EmailProperties seems also to be out of scope for this
> > API
> 
> Agreed, we may need to clarify that the default e-mail account will be used.

I think the account that gets used is something that the user interface
should take care of; typically, when I click on a mailto: link, my mail
user agent lets me choose from which account I would be sending the
mail.


> > * the to field of the email address currently refers to the definition
> > of RFC 5322, which is quite a complicated beast to parse
> > http://tools.ietf.org/html/rfc5322#page-16
> > While I can see the value of accepting these values in the createEmail()
> > function, I think the data exposed through the to[] property should be
> > objects (with e.g. address and name fields) rather than unparsed
> > strings. This would presumably also affect the from, cc and bcc
> > properties, and the relevant MMSProperties. I'm not sure if similar
> > treatments need to be applied to the MSIDN fields in SMS and MMS from
> > fields. 
> 
> I don't think we need to allow developers to specify names in
> to/cc/bcc fields. All they need for sending messages is the e-mail
> address/MSISDN. 

There are two aspects:
* parameters that can be set when creating a message; it would see weird
not to allow to set names (in addition to email addresses) when mailto:
allows for it
* parameters that can be read from the Message object created; having to
parse the fields to extract email address or names would be a disservice
to developers when the browsers could fairly easily make them available
through an object

> The reason for referring to RFC5322 is specifying the format of that
> attribute, as we need to explain what a valid e-mail address is.

RFC5322 defines valid email addresses that include "Dominique
Hazael-Massieux <dom@w3.org>" as well as dom@w3.org, and other niceties
with quoting, line returns, etc.

If we need to restrict some of these fields of a "valid email address",
I think we should use the HTML5 spec definition:
http://dev.w3.org/html5/spec/states-of-the-type-attribute.html#e-mail-state

Thanks,

Dom

Received on Monday, 13 December 2010 15:33:01 UTC