Hi Luiz, > -----Original Message----- > From: linux-bluetooth-owner@xxxxxxxxxxxxxxx <linux-bluetooth- > owner@xxxxxxxxxxxxxxx> On Behalf Of Luiz Augusto von Dentz > Sent: Wednesday, December 18, 2019 5:44 AM > To: Kishore, Ajay <ajay.kishore@xxxxxxxxx> > Cc: linux-bluetooth@xxxxxxxxxxxxxxx > Subject: Re: [PATCH 6/6] doc/obex-api: Update documentation > > Hi Ajay, > > On Mon, Dec 16, 2019 at 1:54 AM Ajay Kishore <ajay.kishore@xxxxxxxxx> > wrote: > > > > This adds documentation with the conversation listing feature > > > > Signed-off-by: Ajay Kishore <ajay.kishore@xxxxxxxxx> > > --- > > doc/obex-api.txt | 65 > > ++++++++++++++++++++++++++++++++++++++++++++++++++++++++ > > 1 file changed, 65 insertions(+) > > > > diff --git a/doc/obex-api.txt b/doc/obex-api.txt index > > f39355a..9a76159 100644 > > --- a/doc/obex-api.txt > > +++ b/doc/obex-api.txt > > @@ -712,6 +712,71 @@ Methods void SetFolder(string name) > > Possible errors: org.bluez.obex.Error.InvalidArguments > > org.bluez.obex.Error.Failed > > > > + > > + > > + array{object, dict} listconversations(string folder, > > + dict filter) > > It should have been ListConversations to adhere with our D-Bus APIs, but > read bellow. Fixed and pushed in the new patch ([PATCH v2 6/6] doc/obex-api: Update documentation). > > > + Returns an array containing the conversations found in the > > + given subfolder of the current folder, or in the current > > + folder if folder is empty. > > + > > + Possible Filters: LastActivityBegin, LastActivityEnd, > > + ReadStatus, Recipient > > So here is the big design question, why hasn't this been done as a filter to > ListMessages? We could just have a couple of different properties to indicate > it is a conversation rather than a single message, in any case we would need > something like > org.bluez.obex.Conversation1 to enumerate these objects, something that is > not documented here. I Agree that the few properties are similar in ListMessages and ListConversations functions and can be implemented to just add few new properties. But we thought to implement both these functions separately as in MAP specification also it is separated. Also with this implementation it will easier to develop separate application for both the feature. In the current implementation we are using org.bluez.obex.Conversation1 interface to enumerate and it is updated in the new patch ([PATCH v2 6/6] doc/obex-api: Update documentation). > > > > + > > + Properties: > > + > > + string id: > > + > > + Conversation unique > > + identification > > + > > + string name: > > + > > + Conversation name > > + > > + string last_activity: > > + > > + Conversation timestamp for the > > + last activity > > + > > + boolean read_status: > > + > > + Conversation read flag > > + > > + string version_counter: > > + > > + 128 bits version counter. > > + The ‘Conversation-Listing Version Counter’, > > + ‘Conversation Version Counter’, and ‘Folder > > + Version Counter’ are used to detect if something > > + has changed > > + > > + string summary: > > + > > + Conversation summary > > + > > + string display: > > + > > + Conversation participants name > > + > > + string chat_state: > > + > > + Conversation current chat > > + state of the participants > > + > > + string presence_availability: > > + > > + Conversation participants > > + availability > > + > > + string presence_text: > > + > > + User defined status of the > > + conversation > > + > > + uint16 priority: > > + > > + Conversation participant > > + priority > > + > > + Possible errors: org.bluez.obex.Error.InvalidArguments > > + org.bluez.obex.Error.Failed > > + > > + > > void UpdateInbox(void) > > > > Request remote to update its inbox. > > -- > > 2.7.4 > > > > > -- > Luiz Augusto von Dentz Thanks. Ajay Kishore