All of lore.kernel.org
 help / color / mirror / Atom feed
From: Santiago Carot-Nemesio <scarot@libresoft.es>
To: linux-bluetooth@vger.kernel.org
Cc: luiz.dentz@gmail.com, epx@signove.com,
	claudio.takahasi@openbossa.org, jcaden@libresoft.es
Subject: Re: HDP proposed api (ver 0.2)
Date: Thu, 06 May 2010 14:51:20 +0200	[thread overview]
Message-ID: <1273150280.3660.12.camel@mosquito> (raw)
In-Reply-To: <1273129699.2094.12.camel@mosquito>

El jue, 06-05-2010 a las 09:08 +0200, Santiago Carot-Nemesio escribió:
> Hi,
> 
> El mié, 05-05-2010 a las 12:55 +0200, José Antonio Santos Cadenas
> escribió:
> > Hi all,
> > 
> > Here is a new proposoal that tries to integrate all that have been comented
> > and proposed in the list, as well as we talked yesterday on the IRC.
> > 
> > There is still one thing that should be discussed, the fd passin issue. 
> > We think that we must talk about this and find the best way for 
> > the implementation as Elvis sugested.
> > 
> > Regards.
> > 
> > ---------------------------------------
> > 
> > BlueZ D-Bus HDP API description
> > ***********************************
> > 
> > Health Device Profile hierarchy
> > ===============================
> > 
> > Service		org.bluez
> > Interface	org.bluez.Hdp
> > Object path	[variable prefix]/{hci0,hci1,...}
> > 
> > Methods		object CreateSession(object path, dict config)
> > 
> > 			Returns the object path for the new HDP session.
> > 			The path parameter is the path of the remote object
> > 			with the callbacks to nofity events (see
> > 			org.bluez.HdpAgent at the end of this document)
> > 			This petition starts an mcap session and also register
> > 			in the SDP is needed
> > 			Dict is defined as bellow:
> > 			{ "data_spec" : The data_spec is the data exchange
> > 					specficication (see section 5.2.10 of
> > 					the specification document),
> > 					(optional)
> > 			  "end_points" : [{ (optional)
> > 				"mdepid" : uint8, (optional)
> > 				"role" : uint8, (mandatory)
> > 				"specs" :[{ (mandatory)
> > 					"dtype" : uint16, (mandatory)
> > 					"description" : string, (optional)
> > 				}]
> > 			  }]
> > 			}
> > 
> > 			if "data_spec" is not set, no SDP record will be
> > 			registerd, so all the other data in the dictionary
> > 			will be ignored
> > 
> > 			Session will be closed by the call or implicitly when
> > 			the programs leaves the bus.
> > 
> > 			Possible errors: org.bluez.Error.InvalidArguments
> > 
> > 		void DeleteSession(object path)
> > 
> > 			Delete the HDP session identified by the object path.
> > 			Also session will be closed if the procces that started
> > 			it is removed from the D-Bus.
> > 
> > 			Possible errors: org.bluez.Error.InvalidArguments
> > 					 org.bluez.Error.NotFound
> > 
> > 		array remote_session_properties GetRemotesSessions()
> > 
> > 			Returns an array with the remote session_properties
> > 			of all the visible devices.
> > 			remote_session_properties is a dictionary like:
> > 			[{"session_id": a_session_identification (int or string,
> > 					 probably the SDP handler + btaddr)
> > 			 "data_spec" : the remote data spec,
> > 			 "end_points":
> > 				 ["mdepid": uint8,
> > 				  "role"  : uint8,
> > 				  "specs" : [{
> > 					  "dtype"	: uint16,
> > 					  "description"	: string, (optional)
> > 				  }]
> > 				 ]
> > 			}]
> > 
> > 			Note that only remotes with a SDP record will be
> > 			notified by this function.
> > 
> > --------------------------------------------------------------------------------
> > 
> > Service		org.bluez
> > Interface	org.bluez.HdpSession
> > Object path	[variable prefix]/{hci0,hci1,...}/{hdp0,hdp1,...}
> > 
> > 		object Connect(remote_session_id)
> > 
> > 			Connects with the remote session and returns its object
> > 			path.
> > 
> > 			Possible errors: org.bluez.Error.InvalidArguments
> > 					 org.bluez.Error.HdpError
> > 
> > 		void Disconnect(object device, boolean delete)
> > 
> > 			Disconnect from the remote device. If delete is true, any
> > 			status will also be deleted. Otherwise, the status will
> > 			be keeped for allowing future reconnections.
> > 
> > 			Possible errors: org.bluez.Error.InvalidArguments
> > 					 org.bluez.Error.NotFound
> > 					 org.bluez.Error.HdpError
> > 
> > --------------------------------------------------------------------------------
> > 
> > Service		org.bluez
> > Interface	org.bluez.HdpRemoteSession
> > Object path	[variable prefix]/{hci0,hci1,...}/{hdp0,hdp1,...}/rem_session_id
> > 
> > 		boolean Echo(array{byte})
> > 
> > 			Sends an echo petition to the remote session. Return True
> > 			if response matches with the buffer sended. If some error
> > 			is detected False value is returned and the associated
> > 			MCL is closed.
> > 
> > 		uint16 OpenDc(byte mdepid, byte config)
> > 
> > 			Creates a new data channel with the indicated config
> > 			to the remote MCAP Data End Point (MDEP).
> > 			The configuration should indicate the channel quality of
> > 			service.
> > 			Returns the data channel id.
> > 
> > 			Possible errors: org.bluez.Error.InvalidArguments
> > 					 org.bluez.Error.HdpError
> > 
> > 		file_descriptor GetDcFd(uint16 mdlid)
> > 
> > 			Gets a file descriptor where data can be readed or
> > 			writed for receive or sent by the data channel.
> > 			Returns the file descriptor
> > 
> > 			Possible errors: org.bluez.Error.InvalidArguments
> > 					 org.bluez.Error.NotFound
> > 					 org.bluez.Error.HdpError
> > 
> > 		void DeleteDc(uint16 mdlid)
> > 
> > 			Deletes a data channel so it will not be available for
> > 			use.
> > 
> > 			Possible errors: org.bluez.Error.InvalidArguments
> > 					 org.bluez.Error.NotFound
> > 					 org.bluez.Error.HdpError
> > 
> > 		void DeleteAllDc()
> > 
> > 			Deletes all data channels so it will not be available
> > 			for use. Typically this function is called when the
> > 			connection with the remote device will be closed
> > 			permanently
> > 
> > 			Possible errors: org.bluez.Error.HdpError
> > 
> > 		uint16 FirstRelDc()
> > 
> > 			Returns the identificator of the first reliable data
> > 			channel (ERTM) connected for this device.
> > 
> > 			Possible errors: org.bluez.Error.HdpError
> 
> I miss a method to get a ReliableChannel, not only the first reliable
> used for association, confirmed services, faults or abnormal conditions
> defined in iso/ieee11073-20601. May be better next method instead above
> one:
> 
> 		uint16  GetReliableDc(boolean first)
> 
> 			Returns the identificator of a reliable  data
> 			channel (ERTM) connected for this device. If first
> 			is True, the first reliable data channel file
> 			descriptor is returned.
> 
> 			Possible errors: org.bluez.Error.HdpError
> 
> Some coments?
> 
> > 
> > 		uint16 GetBestEfforDc()
> > 
> > 			Returns the id of a best effort (streamming) data
> > 			channel if any.
> > 
> > 			Possible errors: org.bluez.Error.NotFound
> > 
> > 		array getStatus()
> > 
> > 			Returns an array with all the data channels available
> > 
> > 			returned array:
> > 			[uint16, ...]
> > 
> > 			Possible errors: org.bluez.Error.NotFound

Because different quality of service is used for specific data traffic
in iso/ieee11073-20601, its possible that applications only are
interested in to get one kind of data channel. May be that above three
functions can be defined like next two:

		array  GetReliableDc()

			Returns an array with all the data channels with ERTM
			configuration. First of all is the FirstReliable channel
			used for specific traffic.

			Possible errors: org.bluez.Error.HdpError

		array GetBestEffortDc()

			Returns an array with all the data channels with Straming
			configuration.

			Possible errors: org.bluez.Error.HdpError

Whit this change I don't see neccessary the getStatus() function.
What do you think?

> > 
> > HDPAgent hierarchy
> > ==================
> > 
> > (this object is implemented by the HDP client an receives notifications)
> > 
> > Service         unique name
> > Interface       org.bluez.HdpAgent
> > Object path     freely definable
> > 
> > 		void DeviceConnected(object path)
> > 
> > 			This method is called whenever a new device connection
> > 			has been established over the control channel of the
> > 			current HDP session. The objectpath contains the object
> > 			path of the remote device.
> > 
> > 		void DeviceDisconnected(object path)
> > 
> > 			This method is called when a remote device is
> > 			disconnected definitively. Any future reconnections
> > 			will fail. Also all data channels associated to this
> > 			device will be closed.
> > 
> > 		void CreatedDc(object path, uint16 mdlid, filedescriptor fd)
> > 
> > 			This method is called when a new data channel is created
> > 			The path contains the object path of the device whith
> > 			the new connection is created, the mdlid the data
> > 			channel identificator and the fd is the file descriptor
> > 			where the data can be readed or writed.
> > 
> > 		void DeletedDc(object path, uint16 mdlid)
> > 
> > 			This method is called when a data channel is closed.
> > 			After this call the data channel will not be valid and
> > 			can be reused for future created data channels.
> > 
> > 		void DataReady(object path, uint16 mdlid, filedescriptor fd)
> > 
> > 			This method is called when there is new data that can be
> > 			readed in a data channel
> > 
> > 		void RemoteSession(dict remote_session_properties)
> > 
> > 			This methos is called when a new session is discorevered
> > 			in a remote device. See Hdp.GetRemotes to know how the
> > 			dictionary is formed.
> 
> > --
> > To unsubscribe from this list: send the line "unsubscribe linux-bluetooth" in
> > the body of a message to majordomo@vger.kernel.org
> > More majordomo info at  http://vger.kernel.org/majordomo-info.html
> 
> 
> --
> To unsubscribe from this list: send the line "unsubscribe linux-bluetooth" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html



  reply	other threads:[~2010-05-06 12:51 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-05-05 10:55 HDP proposed api (ver 0.2) José Antonio Santos Cadenas
2010-05-06  7:08 ` Santiago Carot-Nemesio
2010-05-06 12:51   ` Santiago Carot-Nemesio [this message]
2010-05-06 23:49 ` Elvis Pfützenreuter
2010-05-07 10:03   ` José Antonio Santos Cadenas
2010-05-07 10:07     ` José Antonio Santos Cadenas
2010-05-07 11:24       ` José Antonio Santos Cadenas
2010-05-07 11:26         ` José Antonio Santos Cadenas
2010-05-07 13:52         ` Elvis Pfützenreuter
2010-05-07 13:46     ` Elvis Pfützenreuter
2010-05-07 20:51       ` João Paulo Rechi Vita
2010-05-07 21:08         ` Elvis Pfützenreuter
2010-05-09 15:14           ` Luiz Augusto von Dentz
2010-05-10  8:42             ` José Antonio Santos Cadenas
2010-05-10 12:57               ` José Antonio Santos Cadenas

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=1273150280.3660.12.camel@mosquito \
    --to=scarot@libresoft.es \
    --cc=claudio.takahasi@openbossa.org \
    --cc=epx@signove.com \
    --cc=jcaden@libresoft.es \
    --cc=linux-bluetooth@vger.kernel.org \
    --cc=luiz.dentz@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.