Re: Messaging API comments

On Apr 14, 2010, at 14:56 , Max Froumentin wrote:
> On 07/04/2010 23:58, Suresh Chitturi wrote:
>> *5. Supported messaging types*
>> It would be much cleaner to create separate interface types for each of
>> the message type. Since you have a note to indicate this so it is fine
>> for now!
> 
> Yes, since we separated creation functions for each type, perhaps it makes sense to also separate the message type. Even though it makes for a longer specification but doesn't really improve it.

I don't think that this is a show-stopper for publication. I think that the best way to look at this would be a to compare the two options. If we end up with practically empty subclasses it's probably not worth it.

>> Basically, adding a 'timestamp' attribute of type Date, and a 'status'
>> attribute have the following values: DRAFT, SAVED, SENT.
>> With this combination only one timestamp would suffice and we can also
>> take advantage of the status field for find operations.
> 
> But the idea behind "sent" and "received" is precisely to have 2 timestamps, which has been found useful as discussed at the last face-to-face meeting.

Right. Suresh: you can see in the minutes from the f2f that we looked at this issue and agreed that there was value in knowing both when the message was sent and when it was received. For instance, in my MUA the date that is shown is the sent date, but the messages are sorted by received date.

>> - A 'priority' attribute to indicate the priority of the message: HIGH,
>> MEDIUM/NORMAL, LOW would be very useful. It is very common with emails.
> 
> I think you should propose a separate set of fields that are also very common. Looking at various RFCs, there can be quite a few.

I'd really rather we didn't start adding fields for all the possible uses that there are. One thing that we could do would be to have a setHeader() call similar to XHR but that probably introduces security issues and we'd have to whitelist (or blacklist) the fields.

People who use priority headers in email will be the first against the wall when the revolution comes though, so it might be useful to expose that to build a database of them.

>> - send()
>> I remember we had discussion on how one can use the Contacts API in
>> messaging to be able to populate your "to", "cc", fields with contacts
>> from your address book. Is this still in the scope? We should at least
>> add a note in this regard.
> 
> I'm of the opinion that it should be left independent, but I've noted the issue.

+1 I keep getting implementer feedback that the more orthogonal we keep things the easier it is for them to implement (and therefore, the higher the chances that they'll do it).


Suresh: do the changes that Max has made satisfy your concerns (in terms of FPWD, not forever naturally)?

--
Robin Berjon
  robineko — hired gun, higher standards
  http://robineko.com/

Received on Wednesday, 14 April 2010 13:35:02 UTC