Re: [RFC 0/1] MAP Notification API

Hi Christian,

On Fri, Jul 12, 2013 at 11:23 AM, Luiz Augusto von Dentz
[off-list ref] wrote:

Hi Christian,

On Fri, Jul 12, 2013 at 11:02 AM, Christian Fetzer
[off-list ref] wrote:

quoted

Hi Luiz,

On 07/10/2013 10:56 AM, Luiz Augusto von Dentz wrote:

quoted

Hi Christian,

On Mon, Jun 24, 2013 at 10:56 AM, Christian Fetzer
[off-list ref] wrote:

quoted

From: Christian Fetzer <redacted>

Now that the MAP MNS support is progressing, I'd like to start the discussion
on how the MAP event reports should be signaled in the D-Bus API.

I've listed therefore the 9 different event types and the parameters that we
get from the remote device, together with a proposal on how the API could look
like.


Prerequisite:

The current existing MAP client relies on the fact that the application tracks
the folder a message belongs to. Since notifications can be received for any
folder, it would make sense to remove this restriction and provide a 'Folder'
property for the Message interface. This is needed for the NewMessage,
MessageDeleted, and MessageShift event.


Events:

NewMessage(handle, folder, msg_type):
  - New messages can be signaled by registering a corresponding Message
    interface, that would be announced using the ObjectManager.
  - Since we do not get any meta data, it would make sense to implicitly query
    this information using GetMessagesListing with MaxListCount=1.
    That way, the application would not have to query this data explicitly and
    we would not expose an empty message with no properties set.

Sound good to me.

quoted

DeliverySuccess,SendingSuccess,DeliveryFailure,
SendingFailure(handle, folder, msg_type):
  - This events are only relevant when sending messages (PushMessage).
    Therefore, I'd suggest to register the Message interface already in
    PushMessage for the outgoing message and add a SendingStatus property
    when we receive this events.

I wonder how this is actually implemented, is there a NewMessage event
when using PushMessage? If yes does it indicates Sent flag or we
should listen to this event and notified when it is sent, anyway the
event doesn't give us detailed error so perhaps we could just set
Status to error or something like that, adding another status would be
confusing IMO.

According to the spec, it should be implemented like this:
- The client sends the PushMessage request
- In the response, the server sets the OBEX Name parameter of the last
  response packet to the handle that this message gets on the server.
- The server will try to send the message and will inform the client
  about the status using above notifications. This usually takes some
  seconds (or longer, especially when the reception is bad).

MCE                                    MSE
 | --- PushMessage_Req ---------------> |
 | <-- PushMessage_Res(Name=handle) --- |
             ...
         MSE tries to deliver message
             ...
 | <-- Status event report ------------ |

Note that the type of notification also depend on the network.
Sometimes, the operator accepts all messages (and you only get
SendingSuccess notifications). In error cases, you receive a SMS,
saying that the delivery failed. In this case you get a NewMessage
notification (but only plain text, no status codes).

So if I understand you correctly the NewMessage is only generated when
the message is sent, in that case we should probably create the
message object with the response as you said.

quoted

The idea was, to then register the new message's D-Bus interface
as soon as we have transfered the message to the phone (when we received
the handle in PushMessage_Res). Later, when we receive
a status notification, we update a property in the message.
The Status property could be reused as well here if you don't want a
dedicated property. Does that make sense for you?

The Status should be used as the status of the message not only for
receiving status, for direction we have the Sent property. We should
always try to keep the API as simple as possible so there is less risk
we need to break APIs, adding those latter is possible but I don't
think it will the case here.

quoted

I've done some tests with a BB Z10 to verify that the described
behavior is correct. (see below for a trace)

quoted

quoted

MemoryFull, MemoryAvailable():
  - Add MemoryAvailable property in MessageAccess interface.

It is not very clear how we would use this? Do you actually have any
stack generating these events? Anyway we could also handle it
internally and do not send any data upon receiving MemoryFull, anyway
lets think about it latter.

I don't think we have to 'handle' anything in case of MemoryFull.
This is just an indication for the application/UI that you will
not be able to receive / send any new messages.

Lets concentrate on the other events we can come back to this latter.

Anything coming from your side anything soon or are you waiting some feedback?

-- 
Luiz Augusto von Dentz