Re: Messaging API comments

On 07/04/2010 23:58, Suresh Chitturi wrote:
> Hello,
> Here are a few comments to the Messaging API draft, for consideration
> prior to CfC. Sorry if they are coming late!
> ===========================
> *3. Scope*
> There is nothing in the spec dealing with "as well as inspection and
> manipulation of message folders on a device."
> Should this statement be removed or consider adding a note that this
> functionality is TBD? I would prefer the later since this is quite useful.

Added as an issue.

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

> *6.2 MessagingManager*
> There is no search/find capabilities. This is definitely needed.

That goes under the "functionality for inspecting messages" raised 
issue, no?

> *6.3 Message*
> - ''sent' and 'received' attribute-naming is mis-leading. I think what
> you intended is to associate a timestamp to the message.
> A better approach would be something like the following:
>
> interfaceMessage  : MessageProperties {
>      constunsigned short  SMS_TYPE  <http://dev.w3.org/2009/dap/messaging/#widl-Message-SMS_TYPE>  =1;
>      constunsigned short  MMS_TYPE  <http://dev.w3.org/2009/dap/messaging/#widl-Message-MMS_TYPE>  =2;
>      constunsigned short  EMAIL_TYPE  <http://dev.w3.org/2009/dap/messaging/#widl-Message-EMAIL_TYPE>  =3;
>
>      constunsigned short  STATUS_SAVED  <http://dev.w3.org/2009/dap/messaging/#widl-Message-SMS_TYPE>  = x;
>      constunsigned short  STATUS_DRAFT = x;
>      constunsigned short  STATUS_SENT = x;
>
>      readonly attributeDOMString       id  <http://dev.w3.org/2009/dap/messaging/#widl-Message-id>;
>      readonly attribute unsigned shortstatus  <http://dev.w3.org/2009/dap/messaging/#widl-Message-sent>;
>      readonly attributeDate            timestamp  <http://dev.w3.org/2009/dap/messaging/#widl-Message-received>;
>      readonly attributeunsigned short  type  <http://dev.w3.org/2009/dap/messaging/#widl-Message-type>;
>      PendingOp  send  <http://dev.w3.org/2009/dap/messaging/#widl-Message-send>  (inSuccessCallback  successCB,in optionalErrorCallback  errorCB);
> };
>
> 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.

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

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


> Also, this method will need to define
> exceptions, when a particular attribute is not set based on section 5
> prior to invoking this message. E.g. if this method is invoked without
> setting the "to" field.

Added an exception, which will need to be fleshed out later (noted in an 
issue)

> - Should there be delete/remove, and save methods? Seems logical to have
> them.

This goes along with the message manipulation feature, noted above (and 
in the spec)

Max.


> Regards,
> Suresh
> ---------------------------------------------------------------------
> 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 Wednesday, 14 April 2010 12:57:16 UTC