RE: Messaging API comments

-----Original Message-----
From: Robin Berjon [mailto:robin@robineko.com] 
Sent: Wednesday, April 14, 2010 8:35 AM
To: Max Froumentin
Cc: Suresh Chitturi; public-device-apis@w3.org
Subject: 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.


Suresh>> I believe it does make sense to have separate
interfaces/subclasses for each of them. We are talking about entirely
different types of messaging technologies, and we need specific
behaviors for each of them. This would also allow us to easily extend in
the future and makes the API more modular. More concretely, if you look
at the mapping table with message properties for each type, there is
already a good distinction as to what is applicable to each of them.
However, I do agree this is not a showstopper but at the same time I
believe it is not difficult either to specify it well the first time:-)

>> 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.

Suresh>> Thanks Robin for the clarification, I certainly misunderstood
the intent here. Too bad I missed the F2F! For clarification, do you
anticipate you will have sent and received time stamps for the same
message and for all message types? From my understanding SMS has no way
to tell if it was delivered to the target user and this case you can
only expect sent timestamp. Looks like we need some more thoughts here!

Anyways, what I was trying to is to be able to distinguish the message
based on the status. This is particularly useful, for example when you
want to filter the messages based on 'draft', 'sent', 'saved' messages. 

>> - 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.

Suresh>> I am not sure if it has to be in the form of setHeader(), but
it can be simply an attribute like the proposed one. I use priority flag
and I am sure many of us do at work. Can we add it, please:-)

>> - 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>> Sure, I support this too with the note Max added. Let's take it
up later if needed.


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

Suresh>> I would say partially yes, but as long as we are conscious with
the issues I have raised earlier and my further comments here above, I
am fine with moving to FPWD.

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





---------------------------------------------------------------------
This transmission (including any attachments) may contain confidential information, privileged material (including material protected by the solicitor-client or other applicable privileges), or constitute non-public information. Any use of this information by anyone other than the intended recipient is prohibited. If you have received this transmission in error, please immediately reply to the sender and delete this information from your system. Use, dissemination, distribution, or reproduction of this transmission by unintended recipients is not authorized and may be unlawful.

Received on Tuesday, 20 April 2010 13:27:48 UTC