Proposed MAP API

Proposed MAP API

[Counihan, Tom]

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.

Proposed MAP client D-Bus API (was: Proposed MAP API)

[Johan Hedberg]

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

RE: Proposed MAP client D-Bus API (was: Proposed MAP API)

[Counihan, Tom]

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.

Re: Proposed MAP client D-Bus API (was: Proposed MAP API)

[Johan Hedberg]

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

RE: Proposed MAP client D-Bus API (was: Proposed MAP API)

[Counihan, Tom]

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:johan.hedberg@gmail.com]
>Sent: 14 June 2010 15:16
>To: Counihan, Tom
>Cc: linux-bluetooth@vger.kernel.org
>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.