W3C home > Mailing lists > Public > public-device-apis@w3.org > May 2010

Re: Proposal to update Messaging API

From: Robin Berjon <robin@robineko.com>
Date: Tue, 4 May 2010 16:05:43 +0200
Cc: <public-device-apis@w3.org>
Message-Id: <5B4D4A8E-E609-4801-AD33-F95C28009C24@robineko.com>
To: Suresh Chitturi <schitturi@rim.com>
On Apr 30, 2010, at 23:07 , Suresh Chitturi wrote:
> Here is the proposal to update the current Messaging API, based on our discussion that occurred during this week’s call.

Thanks for taking care of this.

> 2) New attributes such as 'status', 'priority', 'folder'.

For priority I think that we should really rather look at using the generic headers mechanism which we discussed and which I detailed at:

  http://www.w3.org/mid/1704EEAB-58F2-4E8E-8C51-E8BCA9628E85@robineko.com

I don't think that there's a lot of value in making it special (there is more for some of the other headers).

> Note: some missing aspects include
>  
> 1) Search/Find/Filter capabilities
> 2) Folder management (e.g. Copy, Move) – Max had a simple proposal on this which can be added I assume.

It would be good to have a unified proposal folding in Max's suggestions too.

> interface MessagingManager {
>  
>     const unsigned short FOLDER_INBOX = 0;
>     const unsigned short FOLDER_SENT = 1;
>     const unsigned short FOLDER_DRAFT = 2;
>     const unsigned short FOLDER_OUTBOX = 3;
>     const unsigned short FOLDER_DELETED = 4;
>     const unsigned short FOLDER_OTHER = 5;
>  
>     const unsigned short STATUS_SAVED = 0;
>     const unsigned short STATUS_DRAFT= 1;
>     const unsigned short STATUS_SENT = 2;

Last week we discussed using string instead of numerical constants since the latter lead either to uselessly long or uselessly unreadable code. Any thoughts on changing this?

>       //Subscribe
>     int     subscribeOnSMS (in OnIncomingSMS messageEventCB);
>     int     subscribeOnMMS (in OnIncomingMMS messageEventCB);
>     int     subscribeOnEmail (in OnIncomingEmail messageEventCB);

I think that these should just be "onFoo". The "subscribe" bit just makes the method names long.

> ==============
> SMS interfaces
> ==============
> interface SMSMessage : SMSProperties {
>     readonly attribute DOMString      id;
>     readonly attribute Date           timestamp; //determined by the folder (inbox=received time, sent=”sent time”, draft=”created time”)

I don't know SMS very well, does the envelope only have one time field?

Shouldn't the value in draft be "updated time" (if I change it after having created it).

> interface SMSProperties {
>              attribute DOMString[] to;
>              attribute DOMString   body;

Does body always work as a DOMString, including for binary SMSs?

>     readonly attribute DOMString   from;
>     readonly attribute unsigned short folder; //one of FOLDER_* constants determined by the system.
>     readonly attribute unsigned short status: //one of STATUS_* constants determined by the system.

Making "status" part of SMSProperties means that you can set status with createSMS({ status: "sent" }). Shouldn't status be a property of SMSMessage?

> interface MMSMessage : MMSProperties {
>     readonly attribute DOMString      id;
>     readonly attribute Date           timestamp; //determined by the folder (inbox=received time, sent=”sent time”, draft=”created time”)

Same as above.

> interface MMSProperties {
>              attribute DOMString[] to;
>              attribute DOMString[] cc;
>              attribute DOMString[] bcc;
>              attribute DOMString   subject;
>              attribute DOMString   body;
>     readonly attribute DOMString   from;
>     readonly attribute unsigned short folder; //one of FOLDER_* constants determined by the system.
>     readonly attribute unsigned short status: //one of STATUS_* constants determined by the system. 
>              attribute File[]      attachments;

Same as above.

Also, what separates body from attachments? I think that attachments should probably be a list of Blobs rather than of Files but I'm not sure. Thoughts?

> ================
> Email interfaces
> ================
>  
> interface EmailMessage : EmailProperties {
>     readonly attribute DOMString      id;
>     readonly attribute Date           timestamp; //determined by the folder (inbox=received time, sent=”sent time”, draft=”created time”)

As I said above I don't know about SMS and MMS but for email this is very clearly wrong. For received messages there are two fields: sentDate and receivedDate and you need both in order to usefully manipulate email (with your proposal, if I go on vacation for two weeks then check email, they will all be from "today").

>     PendingOp send () raises (EmailException);
>     PendingOp remove();
>     PendingOp save();
> };

I forgot to flag this in the other interfaces, but if there's a PendingOp it means it's an asynch call (which these should be); but then we're missing success and error callbacks!

> interface EmailProperties {
>   const unsigned short PRIORITY_HIGH = 0;
>   const unsigned short PRIORITY_MEDIUM= 1;
>   const unsigned short PRIORITY_LOW = 2;
>              attribute DOMString[] to;
>              attribute DOMString[] cc;
>              attribute DOMString[] bcc;
>              attribute DOMString   subject;
>              attribute DOMString   body;
>              attribute DOMString   accountId; //Indicates the email account Id/name associated with this message
>              attribute unsigned short priority; //default = 1
>     readonly attribute unsigned short folder; //one of FOLDER_* constants determined by the system.
>     readonly attribute unsigned short status: //one of STATUS_* constants determined by the system.
>     readonly attribute DOMString   from;
>              attribute File[]      attachments;
> };

Much of the previous comments apply here.

Furthermore, I wonder if we shouldn't have an EmailAddress interface to expose the details of provided email addresses? I am willing to bet that no one on this list could correctly describe the syntax of RFC 2822 recipients (without looking it up). The alternative is to only provide the raw, preprocessed email addresses but that's not fully helpful since for display people tend to want to have the rest of the data.

RFC 2822 also has recipient groups, but I hope we can avoid that...

--
Robin Berjon
  robineko — hired gun, higher standards
  http://robineko.com/
Received on Tuesday, 4 May 2010 14:06:14 UTC

This archive was generated by hypermail 2.3.1 : Monday, 23 October 2017 14:53:43 UTC