Re: Status of rest proposals (Messaging, Telephony and Raw Sockets)

Hi Wonsuk,

>
> For email, I would like to have use cases for checking the value of this
> API.

Certainly. In short, it would provide functionality to applications to
enumerate configured email accounts, send and receive emails using a
single API, regardless of the service interface and the backend (which
can be a web mail interface, or a native email stack); think of
unified email clients.
The value for apps is to have a single interface for enumerating email
accounts. Specific email services may add capabilities, but the
commons would look the same in all services, e.g. sending an email
takes the same arguments.
- email account configuration is not handled by this API at the moment
(desirably that would be handled by a more generic accounts management
API)
- multiple email accounts are supported through extending the
MessagingService interface (which for SMS and MMS covers for SIM) to
EmailService
- an email message is an extension of an MMS message
- on the navigator.messaging object there is an EmailService object
which is used for default (the other services are enumerable).
Supports:
-  folders and labels
- synchronization on account level and on folder level
- folders can be private to the client or exportable (changes
synchronized to the service)
- partial fetching of emails
- inline attachments
- HTML and plain body.

This spec is meant as a first step and a basis for further discussion,
rather than a push for a spec.

> In case of P2P IM, I think this could make a conflict with Peer to Peer Data
> API of WebRTC Spec[1]. What do you think?

That is one mechanism to send data between apps. The IM API would be
higher level and more generic.
IM functionality assumes
- an account, i.e. a way to identify the IM service and the user,
- presence information (added to ContactProperties.impp) and contact
capabilities (e.g. audio, video, text, file transfer, ...) and support
for whether the contact is transient or not (transient contacts exist
only during a session, e.g. we may not want to save thousands of chat
room participants to persistent storage)
- methods for sending and receiving.
There may be multiple IM accounts used in the same time, e.g.
different users on the same service (two gmail accounts), or on
different services.
The P2P IM API would be very similar to the SMS API, except the added
presence interface (SMS is considered always 'available' when the SIM
card is on), and the different addressing than phone numbers.
The implementation of the API may use WebRTC P2P Data, but in my
thinking the main targeted protocols were XMPP and SIP. Both have
JavaScript implementations, and native implementations. The goal was
to have an API which can handle transparently native stacks vs web
implementations, i.e. applications could work the same way regardless
of the underlying platform implementation details. Connection
setup/bringing the accounts online/account management was not
considered to be part of this API (although it could be included).
So I don't think this would actually conflict with the WebRTC P2P Data spec.

Best regards,
Zoltan

Received on Tuesday, 19 March 2013 10:22:05 UTC