1:52 a.m.
These patches concern mmsd and update TODO and documentation to describe new
functionalities to add to mmsd.
Ronald Tessier (3):
TODO: Add new tasks
doc: Describe delivered group in storage doc
doc: Add new D-Bus methods to service interface
TODO | 67 +++++++++++++++++++++++++++++++++++++++++++++++++++
doc/service-api.txt | 20 +++++++++++++++
doc/storage.txt | 30 ++++++++++++++++++++++
3 files changed, 117 insertions(+), 0 deletions(-)
--
1.7.4.1
1:52 a.m.
New subject: [PATCH 1/3] TODO: Add new tasks
---
TODO | 67 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
1 files changed, 67 insertions(+), 0 deletions(-)
diff --git a/TODO b/TODO
index a4330b3..6e54f6f 100644
--- a/TODO
+++ b/TODO
@@ -16,6 +16,73 @@ Background
once the task is better understood.
+MMS Delivery Report
+===================
+
+- Add delivery report request when sending message.
+ Modify SendMessage D-Bus API to add delivery report request flag.
+ Update message structure to manage this flag.
+ Modify MMS M-Send.Req PDU encoder to encode delivery report request.
+ Modify test script related to message sending to support new delivery flag.
+
+ Priority: Medium
+ Complexity: C2
+ Owner: Ronald Tessier <ronald.tessier(a)linux.intel.com>
+
+- Update message status stored in its associated Meta file.
+ Add a group [delivery_status] in the message status to handle delivery
+ reports, this group contains an entry for each message recipients.
+ Each recipient entry will be updated when the corresponding report will be
+ received and then remove the temporary stored delivery report.
+ Upon M-Send.Conf reception, store the received Message_ID to match delivery
+ reports (needed only if delivery report was requested).
+
+ Priority: Medium
+ Complexity: C2
+ Depends:
+ Owner: Sébastien Bianti <sebastien.bianti(a)linux.intel.com>
+
+- Add MMS M-Delivery.ind PDU decoding support.
+ Modify mms_service_push_notify() to handle MMS Delivery Report WAP Push
+ notification and temporary store the M-Delivery.ind PDU.
+ Decode M-Delivery.ind PDU.
+ Add MMS M-Delivery.ind PDU sample PDU to unit test.
+
+ Priority: Medium
+ Complexity: C2
+ Depends:
+ Owner: Ronald Tessier <ronald.tessier(a)linux.intel.com>
+
+- Update message Meta file.
+ Upon MMS M-Delivery.ind PDU reception, update delivery_status recipient entry
+ with the received status (this is described in doc/storage.txt).
+
+ Priority: Medium
+ Complexity: C2
+ Depends:
+ Owner: Sébastien Bianti <sebastien.bianti(a)linux.intel.com>
+
+
+D-Bus API
+=========
+
+- Add the "org.ofono.mms.Service" interface "DeleteMessages" method
+ implementation.
+ The D-Bus Message API documentation is available under /doc/service-api.txt.
+
+ Priority: Medium
+ Complexity: C2
+ Owner: Sébastien Bianti <sebastien.bianti(a)linux.intel.com>
+
+- Add the "org.ofono.mms.Service" interface "DeleteConversation"
method
+ implementation.
+ The D-Bus Message API documentation is available under /doc/service-api.txt.
+
+ Priority: Medium
+ Complexity: C2
+ Owner: Ronald Tessier <ronald.tessier(a)linux.intel.com>
+
+
Miscellaneous
=============
--
1.7.4.1
1:52 a.m.
New subject: [PATCH 2/3] doc: Describe delivered group in storage doc
---
doc/storage.txt | 30 ++++++++++++++++++++++++++++++
1 files changed, 30 insertions(+), 0 deletions(-)
diff --git a/doc/storage.txt b/doc/storage.txt
index 8e76382..0aa6d9d 100644
--- a/doc/storage.txt
+++ b/doc/storage.txt
@@ -18,6 +18,7 @@ Meta file Example
[info]
read=false
state=notification
+message_id=0123456789ABCDEF
Meta file Keys/Values details
@@ -31,3 +32,32 @@ state: The message local state, possible values can be:
- "received": m-Retrieve.Conf PDU downloaded and successfully
acknowledged.
- "draft": m-Send.Req PDU ready for sending.
- "sent": m-Send.Req PDU successfully sent.
+
+message_id: this is the value provided in the M-Send.conf PDU (assigned by MMSC
+in response to a M-Send.req message), this entry will only be created upon
+M-Send.conf message reception if the delivery report was requested.
+
+For sent messages, a group [delivery_status] could take place in addition to
+[info] if delivery report is requested.
+In this group, every recipient has a MMS Delivery status value which can be one
+of the following:
+ - "none": no report has been received yet.
+ - "expired": recipient did not retrieve the MMS before expiration.
+ - "retrieved": MMS successfully retrieved by the recipient.
+ - "rejected": recipient rejected the MMS.
+ - "deferred": recipient decided to retrieve the MMS at a later time.
+ - "indeterminate": cannot determine if the MMS reached its destination.
+ - "forwarded": recipient forwarded the MMS without retrieving it first.
+ - "unreachable": recipient is not reachable.
+
+
+Example of a sent_message meta file with delivery report requested
+==================================================================
+
+[info]
+state=sent
+message_id=0123456789ABCDEF
+
+[delivery_status]
+21345=retrieved
+09876=none
--
1.7.4.1
7:43 p.m.
New subject: [PATCH 2/3] doc: Describe delivered group in storage doc
Hi Ronald,
doc/storage.txt | 30 ++++++++++++++++++++++++++++++
1 files changed, 30 insertions(+), 0 deletions(-)
diff --git a/doc/storage.txt b/doc/storage.txt
index 8e76382..0aa6d9d 100644
--- a/doc/storage.txt
+++ b/doc/storage.txt
@@ -18,6 +18,7 @@ Meta file Example
[info]
read=false
state=notification
+message_id=0123456789ABCDEF
I would just shortcut this to "id". Or is the a reason to keep
"message_id" for this?
Meta file Keys/Values details
@@ -31,3 +32,32 @@ state: The message local state, possible values can be:
- "received": m-Retrieve.Conf PDU downloaded and successfully
acknowledged.
- "draft": m-Send.Req PDU ready for sending.
- "sent": m-Send.Req PDU successfully sent.
+
+message_id: this is the value provided in the M-Send.conf PDU (assigned by MMSC
+in response to a M-Send.req message), this entry will only be created upon
+M-Send.conf message reception if the delivery report was requested.
+
+For sent messages, a group [delivery_status] could take place in addition to
+[info] if delivery report is requested.
+In this group, every recipient has a MMS Delivery status value which can be one
+of the following:
+ - "none": no report has been received yet.
+ - "expired": recipient did not retrieve the MMS before expiration.
+ - "retrieved": MMS successfully retrieved by the recipient.
+ - "rejected": recipient rejected the MMS.
+ - "deferred": recipient decided to retrieve the MMS at a later time.
+ - "indeterminate": cannot determine if the MMS reached its destination.
+ - "forwarded": recipient forwarded the MMS without retrieving it first.
+ - "unreachable": recipient is not reachable.
+
+
+Example of a sent_message meta file with delivery report requested
+==================================================================
+
+[info]
+state=sent
+message_id=0123456789ABCDEF
+
+[delivery_status]
+21345=retrieved
+09876=none
How is this suppose to work. I am kinda failing to see what this tries
to solve.
Regards
Marcel
7:33 a.m.
New subject: [PATCH 2/3] doc: Describe delivered group in storage doc
Hi Marcel,
On 06/07/2012 04:43 AM, Marcel Holtmann wrote:
Hi Ronald,
> doc/storage.txt | 30 ++++++++++++++++++++++++++++++
> 1 files changed, 30 insertions(+), 0 deletions(-)
>
> diff --git a/doc/storage.txt b/doc/storage.txt
> index 8e76382..0aa6d9d 100644
> --- a/doc/storage.txt
> +++ b/doc/storage.txt
> @@ -18,6 +18,7 @@ Meta file Example
> [info]
> read=false
> state=notification
> +message_id=0123456789ABCDEF
I would just shortcut this to "id". Or is the a reason to keep
"message_id" for this?
Let's go for "id"
> Meta file Keys/Values details
> @@ -31,3 +32,32 @@ state: The message local state, possible values can be:
> - "received": m-Retrieve.Conf PDU downloaded and successfully
acknowledged.
> - "draft": m-Send.Req PDU ready for sending.
> - "sent": m-Send.Req PDU successfully sent.
> +
> +message_id: this is the value provided in the M-Send.conf PDU (assigned by MMSC
> +in response to a M-Send.req message), this entry will only be created upon
> +M-Send.conf message reception if the delivery report was requested.
> +
> +For sent messages, a group [delivery_status] could take place in addition to
> +[info] if delivery report is requested.
> +In this group, every recipient has a MMS Delivery status value which can be one
> +of the following:
> + - "none": no report has been received yet.
> + - "expired": recipient did not retrieve the MMS before expiration.
> + - "retrieved": MMS successfully retrieved by the recipient.
> + - "rejected": recipient rejected the MMS.
> + - "deferred": recipient decided to retrieve the MMS at a later time.
> + - "indeterminate": cannot determine if the MMS reached its
destination.
> + - "forwarded": recipient forwarded the MMS without retrieving it
first.
> + - "unreachable": recipient is not reachable.
> +
> +
> +Example of a sent_message meta file with delivery report requested
> +==================================================================
> +
> +[info]
> +state=sent
> +message_id=0123456789ABCDEF
> +
> +[delivery_status]
> +21345=retrieved
> +09876=none
How is this suppose to work. I am kinda failing to see what this tries
to solve.
If the delivery-report is requested, a delivery_status group will be
created in the message meta file. This group will be used to manage the
received delivery_report sent by each recipients. This group will have
an entry per recipient, the associated value will be set to "none"
(which means no report has been received yet) and updated upon report
reception. The stored "id" (provided by the MMSC in the Send.conf msg)
must match the received "id" in the delivery.ind push msg sent by each
recipients.
This intents to handle and store delivery reports received status. Next
step will be to define how to let the upper layer knows about the
delivery reporting status.
Best regards,
Ronald
1:52 a.m.
New subject: [PATCH 3/3] doc: Add new D-Bus methods to service interface
---
doc/service-api.txt | 20 ++++++++++++++++++++
1 files changed, 20 insertions(+), 0 deletions(-)
diff --git a/doc/service-api.txt b/doc/service-api.txt
index 36e1161..5c18cad 100644
--- a/doc/service-api.txt
+++ b/doc/service-api.txt
@@ -63,6 +63,26 @@ Methods array{object,dict} GetMessages()
[service].Error.PermanentContentNotAccepted
[service].Error.PermanentLackOfPrepaid
+ [TODO] void DeleteMessages(array{object})
+
+ Delete an array of message objects that represents
+ the currently stored messages to delete.
+
+ Possible Errors: [service].Error.InvalidArguments
+
+ [TODO] void DeleteConversation(string number)
+
+ Delete the messages that belongs to the conversation
+ defined by the given number.
+
+ The number parameter contains digits to look for
+ (i.e.: n last digits of the phone number), only messages
+ with a recipient which ends with the given number will
+ be member of the conversation and thus will be deleted.
+
+ Possible Errors: [service].Error.InvalidArguments
+
+
Signals MessageAdded(object path, dict properties)
Signal that is sent when a new message is added. It
--
1.7.4.1
7:43 p.m.
New subject: [PATCH 3/3] doc: Add new D-Bus methods to service interface
Hi Ronald,
doc/service-api.txt | 20 ++++++++++++++++++++
1 files changed, 20 insertions(+), 0 deletions(-)
diff --git a/doc/service-api.txt b/doc/service-api.txt
index 36e1161..5c18cad 100644
--- a/doc/service-api.txt
+++ b/doc/service-api.txt
@@ -63,6 +63,26 @@ Methods array{object,dict} GetMessages()
[service].Error.PermanentContentNotAccepted
[service].Error.PermanentLackOfPrepaid
+ [TODO] void DeleteMessages(array{object})
I do not like the [TODO] annotation here. Left that out.
+
+ Delete an array of message objects that represents
+ the currently stored messages to delete.
+
+ Possible Errors: [service].Error.InvalidArguments
+
+ [TODO] void DeleteConversation(string number)
+
+ Delete the messages that belongs to the conversation
+ defined by the given number.
+
+ The number parameter contains digits to look for
+ (i.e.: n last digits of the phone number), only messages
+ with a recipient which ends with the given number will
+ be member of the conversation and thus will be deleted.
+
+ Possible Errors: [service].Error.InvalidArguments
+
+
Signals MessageAdded(object path, dict properties)
Signal that is sent when a new message is added. It
Regards
Marcel
3144
days inactive
3151
days old
7 comments
2 participants
participants (2)
-
Marcel Holtmann -
Ronald Tessier