Hi Christian, On Wed, Aug 7, 2013 at 12:15 PM, Luiz Augusto von Dentz <luiz.dentz@xxxxxxxxx> wrote: > Hi Christian, > > On Fri, Jul 12, 2013 at 11:23 AM, Luiz Augusto von Dentz > <luiz.dentz@xxxxxxxxx> wrote: >> Hi Christian, >> >> On Fri, Jul 12, 2013 at 11:02 AM, Christian Fetzer >> <christian.fetzer@xxxxxxxxxxxxxxxx> wrote: >>> Hi Luiz, >>> >>> On 07/10/2013 10:56 AM, Luiz Augusto von Dentz wrote: >>>> Hi Christian, >>>> >>>> On Mon, Jun 24, 2013 at 10:56 AM, Christian Fetzer >>>> <christian.fetzer@xxxxxxxxxxxxxxxx> wrote: >>>>> From: Christian Fetzer <christian.fetzer@xxxxxxxxxxxx> >>>>> >>>>> 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. >>>> >>>>> 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. >> >>> 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. >> >>> I've done some tests with a BB Z10 to verify that the described >>> behavior is correct. (see below for a trace) >>> >>>>> 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? We are still lacking the processing of the events in obexd/client/map.c:map_handle_notification, are you going to send the patches to add it? -- Luiz Augusto von Dentz -- To unsubscribe from this list: send the line "unsubscribe linux-bluetooth" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
