Hi Folks,
Please find below proposed Bluetooth MAP API, based upon Message Access Profile, ver 10r00.
Comments most welcome.
Of note below is missing the PushMessage function - Section 5.8 of mentioned spec.
Reason being, I'm trying to get my head around what should be returned from a GetMessage call below, and conversely what should be passed to a potential PushMessage - bMessage can take on a number of different guises.
Any guidance/opinion would be greatly appreciated in this area, or any other suggested improvements.
Warm Regards
Tom.
------------------------------------------
Message Access hierarchy
=======================
Service org.openobex.client
Interface org.openobex.MessageAccess
Object path [variable prefix]/{session0,session1,...}
Methods void SetFolder(string folder)
Change the current folder of the remote MSE device
dict GetProperties()
Returns all properties for the interface. See the
properties section for available properties.
array{string} GetFolderListing()
Returns a Folder-Listing containing information about
the current folder content. The return shall not contain
message entries.
array{dict} GetMessageListing()
Returns a dictionary containing information about
the current folder's Message content.
The following keys are defined:
uint64 Handle: Unique handle for message
string subject: summary of message
string datetime: timestamp in format "YYYMMDDTHHMMSS"
string senderName: name of sender
string senderAddressing: address info of sender
string replytoAddressing: Reply-To info of sender
string recipientName: name of recipient
string recipientAddressing: address info of recipient
string type: ("EMAIL" | "SMS_GSM" | "SMS_CDMA" | "MMS")
string size: Size in bytes of original message
string text: ("yes"|"no") - text vs binary content
string receptionStatus: reception status on MSE
string attachmentSize: size of attachment in bytes
string priority: ("yes"|"no") - high or no priority
string read: ("yes"|"no") has message been read on MSE
string sent: ("yes"|"no") has message been sent
string protected: ("yes"|"no") is all/part DRM protected
string GetMessage(uint64 handle)
Retrieves a messages, identified by unique handle from MSE.
void UpdateInbox()
Trigger the MSE to update its inbox.
void SetReadStatus(uint64 handle, string status)
Sets the messges's read status on the MSE
handle: unique handle for the message
status: "yes" sets message status to read
"no" sets message status to unread
void SetDeletStatus(uint64 handle, string status)
Sets the messges's delete status on the MSE
handle: unique handle for the message
status: "yes" sets message status to delete
"no" sets message status to non-delete
void EnableNotification()
Request the MSE to send message notification events
void DisableNotification()
Request the MSE to disable message notifications.
Signals MessageEventReport(dict)
Sent when an event on the MSE affects is message listing.
The following keys are defined:
string type: ("NewMessage" | " DeliverySuccess" |
"SendingSuccess" | "DeliveryFailure" |
"SendingFailure" | "MemoryFull" |
"MemoryAvailable" | "MessageDeleted" | "MessageShifted")
uint64 handle: Unique handle for message
string folder: name of folder, including path which message has been populated on MSE
string oldFolder: Facilitates moving msgs between folders
string msgType: ("EMAIL" | "SMS_GSM" | "SMS_CDMA" | "MMS")
Properties boolean NotificationEnabled [readonly]
Reflects if MSE has been directed to send message Notification
--------------------------------------------------------------
Intel Shannon Limited
Registered in Ireland
Registered Office: Collinstown Industrial Park, Leixlip, County Kildare
Registered Number: 308263
Business address: Dromore House, East Park, Shannon, Co. Clare
This e-mail and any attachments may contain confidential material for the sole use of the intended recipient(s). Any review or distribution by others is strictly prohibited. If you are not the intended recipient, please contact the sender and delete all copies.
Thanks Johan,
I'll attempt to get something kick started on gitorious along the lines of your suggestion.
Warm regards
Tom.
>-----Original Message-----
>From: Johan Hedberg [mailto:[email protected]]
>Sent: 14 June 2010 15:16
>To: Counihan, Tom
>Cc: [email protected]
>Subject: Re: Proposed MAP client D-Bus API (was: Proposed MAP API)
>
>Hi Tom,
>
>On Mon, Jun 14, 2010, Counihan, Tom wrote:
>> Many thanks for the prompt response Johan,
>
>No problem :)
>
>> Not sure at all really. I had my suspicion, but wanted to start
>somewhere.
>> What you suggest makes perfect sense really - back to the drawing
>> board for me :$ - just need to figure out a logical home for this.
>
>Note that I'm not strictly saying that it can't be D-Bus based. Only
>that there's a considerable risk with that and that you should
>understand the pros and cons of the different alternatives. E.g.
>compared to D-Bus a library would restrict you more in terms of what
>programing languages can be used for the application whereas there's
>quite a plethora of D-Bus bindings out there. You'd also need to
>consider potential multithreading issues and pay close attention in
>designing the API so that it can be conveniently hooked up to whatever
>mainloop the application has, or then simply decide that only one
>mainloop, e.g. the glib one, is supported.
>
>> On an aside, could the same comment be made regarding PBAP re contact
>> pictures?
>
>Yes, I think so.
>
>Johan
--------------------------------------------------------------
Intel Shannon Limited
Registered in Ireland
Registered Office: Collinstown Industrial Park, Leixlip, County Kildare
Registered Number: 308263
Business address: Dromore House, East Park, Shannon, Co. Clare
This e-mail and any attachments may contain confidential material for the sole use of the intended recipient(s). Any review or distribution by others is strictly prohibited. If you are not the intended recipient, please contact the sender and delete all copies.
Hi Tom,
On Mon, Jun 14, 2010, Counihan, Tom wrote:
> Many thanks for the prompt response Johan,
No problem :)
> Not sure at all really. I had my suspicion, but wanted to start somewhere.
> What you suggest makes perfect sense really - back to the drawing
> board for me :$ - just need to figure out a logical home for this.
Note that I'm not strictly saying that it can't be D-Bus based. Only
that there's a considerable risk with that and that you should
understand the pros and cons of the different alternatives. E.g.
compared to D-Bus a library would restrict you more in terms of what
programing languages can be used for the application whereas there's
quite a plethora of D-Bus bindings out there. You'd also need to
consider potential multithreading issues and pay close attention in
designing the API so that it can be conveniently hooked up to whatever
mainloop the application has, or then simply decide that only one
mainloop, e.g. the glib one, is supported.
> On an aside, could the same comment be made regarding PBAP re contact
> pictures?
Yes, I think so.
Johan
Many thanks for the prompt response Johan,
>It'd have been good to clearly state that you're only talking about the
>client side of MAP (it became clear to me only after noticing that
>you've got org.openobex.client in the D-Bus API). The server side would
>e.g. be implemented through an obexd plugin.
Duly noted, apologies for any confusion. Note, I'm interested in bringing both sides of this interface up, the original was a modest attempt at kick starting myself on this profile.
>Are you sure you want to use D-Bus for this? I suspect the required
>bandwidth will be too high to be efficiently handled using D-Bus.
>Wouldn't a MAP specific library on top of OpenOBEX make more sense?
Not sure at all really. I had my suspicion, but wanted to start somewhere.
What you suggest makes perfect sense really - back to the drawing board for me :$ - just need to figure out a logical home for this.
On an aside, could the same comment be made regarding PBAP re contact pictures?
Warm Regards
Tom.
--------------------------------------------------------------
Intel Shannon Limited
Registered in Ireland
Registered Office: Collinstown Industrial Park, Leixlip, County Kildare
Registered Number: 308263
Business address: Dromore House, East Park, Shannon, Co. Clare
This e-mail and any attachments may contain confidential material for the sole use of the intended recipient(s). Any review or distribution by others is strictly prohibited. If you are not the intended recipient, please contact the sender and delete all copies.
Hi Tom,
On Mon, Jun 14, 2010, Counihan, Tom wrote:
> Please find below proposed Bluetooth MAP API, based upon Message
> Access Profile, ver 10r00.
It'd have been good to clearly state that you're only talking about the
client side of MAP (it became clear to me only after noticing that
you've got org.openobex.client in the D-Bus API). The server side would
e.g. be implemented through an obexd plugin.
> Comments most welcome.
> Of note below is missing the PushMessage function - Section 5.8 of
> mentioned spec.
> Reason being, I'm trying to get my head around what should be returned
> from a GetMessage call below, and conversely what should be passed to
> a potential PushMessage - bMessage can take on a number of different
> guises.
> Any guidance/opinion would be greatly appreciated in this area, or any
> other suggested improvements.
Are you sure you want to use D-Bus for this? I suspect the required
bandwidth will be too high to be efficiently handled using D-Bus.
Wouldn't a MAP specific library on top of OpenOBEX make more sense?
Johan