Re: Messaging - SMS API draft

Hi Zoltan,

Best regards.

> De:   Kis, Zoltan <zoltan.kis@intel.com>
> Enviado el:   miércoles, 24 de octubre de 2012 19:51
> Para: EDUARDO FULLEA CARRERA
> CC:   public-sysapps@w3.org
> Asunto:       Re: Messaging - SMS API draft
>
> Hello, On Wed, Oct 24, 2012 at 6:45 PM, EDUARDO FULLEA CARRERA
> <efc@tid.es> wrote: Hi all,
>
> I have uploaded an initial draft of the SMS API [1], which is based to a great
> extent on the
> Firefox OS (B2G) WebSMS API [2], and which has been jointly prepared by
> Jose M.
> Cantera and myself, willing to act as co-editors of this spec.
>
> Looking forward to your feedback.
>
> Regards,
> Eduardo.
>
> [1] http://sysapps.github.com/sysapps/proposals/Messaging/SMS.html
> [2] https://wiki.mozilla.org/WebAPI/WebSMS
>
> Just a some  quick notes:
>
> - should we support standard folders line inbox, sent, drafts, outbox, saved,
> and custom
> ones?
>
Current API is enough to implement an SMS client with a conversational UI. However you are right we may need folders or rather the more flexible labels to facilitate sorts of UI models, like a classical view in folders.

> - 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 am open to start discussing on search/filters from a general point of view.

>
> - IMO we should design this API together with MMS, email and p2p IM
> API's, in order to align them as much as possible, since many attributes
> and use cases will be common. Should I send proposals for these?
>
These different services have commonalities but also differences. I think we should go for independent API for each of them, otherwise a single API would be way too complicated, but agree that we need to seek maximum alignment between them.

> - I assume binary SMS with port is not covered by this API. Will we
> define Push Messaging API too?

Binary SMS is not covered by current API. I would go for a separate API for that use case, as I see more differences than commonalities between both use cases, indeed I cannot think of any of the functionalities currently in the API being reused 'as is' for binary SMS.
>
> Best regards,
> Zoltan

________________________________

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 Thursday, 25 October 2012 08:31:45 UTC