Re: Messaging - SMS API draft

On Fri, Oct 26, 2012 at 3:37 PM, EDUARDO FULLEA CARRERA <efc@tid.es> wrote:
>
> I agree we may need folders/tags for those clients not willing to implement a conversational view but a 'classical' view

Yes. There can be many labels per message. Folders are special labels,
as there can be only one folder per message.

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

You mean for SMS and MMS? Yes, this too is possible, since it is an
implementation detail, and has no effect on the API itself.
With the same API one should be able to implement both user experiences.

However, consider that in this case the middleware / backend is your "server".
We have to think what happens if there is race condition between 2
apps of the same kind on the shared middleware.
>From the moment of the first sending attempt, there should be a
transaction started between the app and the backend, with timeout, and
we should be careful when and how the data ownership is transferred.
This would be simpler to implement with the "shared" model (we anyway
need to implement data change notifications). It is also seems more
logical to me that the message belongs to the account (user) rather
than to the app. Not pushing for this, just thinking. Only that I want
to avoid hardcoded assumptions built into the API's.
Nevertheless, as said, this detail doesn't affect the API, only its
particular implementation, but it's good that we discussed it.

Best regards,
Zoltan

Received on Friday, 26 October 2012 13:13:06 UTC