Re: Messaging - SMS API draft

On Fri, Oct 26, 2012 at 1:46 PM, Mounir Lamouri <mounir@lamouri.fr> wrote:
> On 10/24/2012 07:51 PM, Kis, Zoltan wrote:
>> Just a some  quick notes:
>>
>> - should we support standard folders line inbox, sent, drafts, outbox,
>> saved, and custom ones?
>
> I'm not sure why this is needed. This API tries to be higher level than
> those folders. A received message will be in Inbox, those sent in Sent.

One of the basic use cases will be to build UI's with folder or
conversation views.
This is deeply tied with storage, which could be accessed by native
side too, so it would be good to have API's for it.
It just takes a few attributes more (for conversationId, folderId, tags, etc).

>
> Outbox and Draft should probably be handled by the app itself. If I
> receive or send a message, I would expect them to be in APP1 and APP2.
> However, if I try to send a message from APP1, seeing a "Retry" UI in
> APP2 might be odd.

It is not the app who does the sending. Depending on design, you can
have the true Outbox in the middleware, or in JS. I agree with you in
the 2nd case. Again, the difference is in our implicit assumptions
about the platform.
In no case you would be compelled to see a "Retry" UI. The middleware
will send it at the next possible time. Until then, you will correctly
see the message in the Outbox from both apps, since that is the status
of the message. The message belongs to the user, not to the app, and
there is one message, viewed from 2 apps.

> Same thing with drafts: I wouldn't expect a draft
> wrote in APP1 to show up in APP2. The current API allows application to
> have the exact Outbox/Drafts behaviour.

Actually I do expect a draft shown up in the second app, for the
previously mentioned reason: the message belongs to the user (the
account), not to the app. Analogy: if you open gmail from 2 browsers,
you see the same draft in both.

>
>> - should we remove search and filtering for now, and discuss this
>> together with call history search and other similar use cases? Call
>> history API was omitted exactly because of this reason.
>> Or, alternatively, we could discuss this subject in general now, come up
>> with a pattern and use it in every API.
>
> I think the first released document should probably include this because
> it's a basic feature.

A not yet aligned feature, which is controversial at the moment.
We need filtering and search in many other API's as well.
It's a basic feature yes, but this is no good reason to define
eventually diverging filtering in each and every API separately.
This was the reason why the call history API was withheld. It is a
basic feature there too. As it is in Contacts. And in other Messaging
API's.

Anyway, the author of the proposal agreed to discuss filters and searching.
Chris Dumez has proposed one in the Contact API. Alternative proposals
are welcome. We need to solve this, agree on it and move on.

Best regards,
Zoltan

>
> --
> Mounir
>
> ---------------------------------------------------------------------
> Intel Finland Oy
> Registered Address: PL 281, 00181 Helsinki
> Business Identity Code: 0357606 - 4
> Domiciled in Helsinki
>
> This e-mail and any attachments may contain confidential material for
> the sole use of the intended recipient(s). Any review or distribution
> by others is strictly prohibited. If you are not the intended
> recipient, please contact the sender and delete all copies.
>

Received on Friday, 26 October 2012 11:27:25 UTC