Re: Messaging - SMS API draft

On Thu, Nov 15, 2012 at 3:46 PM, Mounir Lamouri <mounir@lamouri.fr> wrote:
> On 26/10/12 12:26, 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.

Support for labels and user folders is useful, and easy.

>>
>> 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).
>
> But then you might want to index the database on those values to have
> fast message retrievals but if an app wants to show a simple stream
> ordered by date, it might not work that well so we would need to index
> messages with their date. Take the concept farther and you end up in a
> ridiculous situation when most of the DB is indexed.

This is possible to solve, but the API should be agnostic to the
database (data source) design. It just should not create obstacles for
database optimizations. We implemented generic filters on many kinds
of databases, and they work fine. What we could do is to concentrate
on the key use cases, and only create the related indexes.
On the API level we could keep generic filters, but mention which
queries are important, like:
- contact list ordered by name, company, presence
- messaging conversation view (usually requiring complex queries),
ordered by time
- messaging label view
- messaging folder view
- call history ordered by time, status (new, missed, dialed, received)
- call history in conversation view.

This list may vary product by product, but the _API_ should make them
all _possible_. As far as I have designed, the find() methods could
take both complex and simple filters, so the implementations have a
choice on what they want to support. Would that be good enough?

> Jonas and I have been speaking a lot about that and our feeling is that
> we assume that SMS apps will simply to a copy of the system database and
> try to keep in sync with changes. This is not a formal proposal but just
> an idea we had because anything we might come with now (having
> conversationId for example) might not work well with some UI concept,
> anyway.

This is a valid and good idea. I played a bit with Jonas' proposal,
and ended up using it in my Messaging and Call History draft, with a
small addition (auto updates with client-controlled low-pass
filtering, plus support for 2-way sync).

>>> 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.
>
> The difference is that you open GMail in both cases. And anyway, GMail
> lives in the cloud. Also, emails by definition, are synced with your server.
> In the other hand, SMS are saved in your device (rarely synced AFAIK).
> This said, I do not have a very strong opinion about this. I'm just not
> very enthusiast in adding a method that would allow writing messages in
> the DB.

Yes, this is service dependent, app designer choice dependent, and
user setting dependent.
There are 2 main use cases:
1. We have 2 SMS apps. A draft SMS made with one should be visible
from the other (if the designer or the user wants it that way).
2. We have 2 SIM cards. The app writer should have a choice in how to
present messages (drafts included), either with total vertical
separation between SIM cards, or together. This is similar with email
accounts.
I definitely want to avoid pushing a UI model. I just want to provide
mechanisms for implementing the designer/user choices, without
hardcoded policies. Inbox and Sent are enough as minimum, but designer
decides. It's not mandatory to use labels, or folders, or
conversations, either. But it should be possible.

Best regards,
Zoltan

Received on Thursday, 15 November 2012 15:56:35 UTC