RE: Proposal to update Messaging API

From: Robin Berjon [mailto:robin@robineko.com] 
Sent: Tuesday, May 04, 2010 9:06 AM

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

Suresh>> I have no strong opinion here as long as we have support from
priority bit. A general comment is that we need to come up with a list
of headers before we commit to a generic header mechanism.

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

Suresh>> Sure. I will update this proposal with Max's additions.

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

Suresh>> My only concern is that string-based access can impact
performance due to needless parsing overhead, compared to constants.
This is a design decision that can apply to other APIs as well. We
should perhaps have a wider discussion on this subject.

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

Suresh>> You mean "onSMS", "onMMS" and "onEmail"? That's fine with me.

> ==============
> 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?

Suresh>> Not sure, but my guess is just one time field.

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

Suresh>> Good point. It should be "updated" or "last saved" time.

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

Suresh>> It is readonly, but maybe moving all readonly attributes from
XXXProperties to XXXMessage is something to consider.

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

Suresh>> I'm open to suggestions. File was used in the current draft so
I simply stuck to it.

> ================
> 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").

Suresh>> It depends on the implementation. My outlook for example, keeps
the date received on the exchange server. For simplicity, my preference
is to stick to one time field. Can we add the sentDate field to the
header?

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





---------------------------------------------------------------------
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, 5 May 2010 03:26:31 UTC