RE: Messaging - SMS API draft

On 26 oct 2012 at 13:26:55, Kis, Zoltan wrote:
> 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).
>

I agree we may need folders/tags for those clients not willing to implement a conversational view but a 'classical' view

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

Gmail is a different case as the drafts are stored in the server. I agree with Mounir that Drafts and Outbox should be local to the app.

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

________________________________

Este mensaje se dirige exclusivamente a su destinatario. Puede consultar nuestra política de envío y recepción de correo electrónico en el enlace situado más abajo.
This message is intended exclusively for its addressee. We only send and receive email on the basis of the terms set out at:
http://www.tid.es/ES/PAGINAS/disclaimer.aspx

Received on Friday, 26 October 2012 12:37:32 UTC