From: "Gustavo F. Padovan" <gustavo@padovan.org>
To: Marcel Holtmann <marcel@holtmann.org>
Cc: "José Antonio Santos Cadenas" <santoscadenas@gmail.com>,
linux-bluetooth@vger.kernel.org
Subject: Re: Proposed API for HDP
Date: Thu, 8 Jul 2010 16:17:55 -0300 [thread overview]
Message-ID: <20100708191755.GD26759@vigoh> (raw)
In-Reply-To: <1278610788.10421.51.camel@localhost.localdomain>
>
> > --------------------------------------------------------------------------------
> >
> > Service org.bluez
> > Interface org.bluez.HealthDeviceApplication
> > Object path [variable prefix]/{hci0,hci1,...}/dev_XX_XX_XX_XX_XX_XX/hdp_YYYY
> >
>
> That is more like the org.bluez.HealthService as mentioned above. So
> lets combine them. I don't see a need for splitting these.
>
> > Methods:
> >
> > array GetProperties()
> >
> > Gets the information of the remote application published on its
> > SDP record. The returned data format is as follows:
> >
> > {
> > "end_points": [
> > "mdepid": uint8,
> > "role" : "source" or "sink" ,
> > "specs" : [{
> > "dtype" : uint16,
> > "description" : string, (optional)
> > }]
> > ]
> > }
> >
> > object Connect(path local_application_id)
> >
> > Connects the local application with the remote application.
> >
> > Only the bus client that created the local session will be able
> > to create connections using it.
> >
> > If the Device is already connected with an other application an
> > org.bluez.Error.AlreadyConnected error will be received.
> >
> > Possible errors: org.bluez.Error.InvalidArguments
> > org.bluez.Error.AlreadyConnected
> > org.bluez.Error.HealthError
> >
> > void Disconnect()
> >
> > Disconnect from the remote application the state will also be
> > deleted. And no future reconnections will be possible. For
> > keeping the state the method Pause of the health link should be
> > used.
> >
> > Possible errors: org.bluez.Error.InvalidArguments
> > org.bluez.Error.NotFound
> > org.bluez.Error.HealthError
>
> Do we need Connect() and Disconnect() here. Can we just not create these
> connections in the background based of a reference counting via the
> channels?
>
> > boolean Echo(array{byte})
> >
> > Sends an echo petition to the remote intance. Returns True if
> > response matches with the buffer sent. If some error is detected
> > False value is returned and the associated MCL is closed.
> >
> > path OpenDataChannel(byte mdepid, string conf)
> >
> > 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 using one of this values "reliable", "streaming", "any".
> >
> > Returns the data channel path.
> >
> > Possible errors: org.bluez.Error.InvalidArguments
> > org.bluez.Error.HealthError
> >
> > void ReconnectDataChannel(path data_channel)
> >
> > Reconnects a previously created data channel indicated by its
> > path.
> >
> > Possible errors: org.bluez.Error.InvalidArguments
> > org.bluez.Error.HealthError
> > org.bluez.Error.NotFound
> >
> > int GetDataChannelFileDescriptor(path data_channel)
> >
> > Gets a file descriptor where data can be read or written.
> >
> > Possible errors: org.bluez.Error.InvalidArguments
> > org.bluez.Error.NotFound
> > org.bluez.Error.HealthError
> >
> > void DeleteDataChannel(path data_channel)
> >
> > Deletes a data channel so it will not be available to use.
> >
> > Possible errors: org.bluez.Error.InvalidArguments
> > org.bluez.Error.NotFound
> > org.bluez.Error.HealthError
> >
> > void DeleteAllDataChannels()
> >
> > Deletes all data channels so they will not be available for
> > future use. Typically this function is called when the
> > connection with the remote device will be closed permanently.
> >
> > Possible errors: org.bluez.Error.HealthError
>
> This actually means also Disconnect() to me. So clear the extra work of
> connect and disconnect can be done in the background and invisible for
> the user.
>
> > dict GetDataChannelStatus()
> >
> > Return a dictionary with all the data channels that can be used
> > to send data right now. The dictionary is formed like follows:
> >
> > {
> > "reliable": [channel_path_r1, channel_path_r2, ...],
> > "streaming" : [channel_path_s1, channel_path_s2, ...]
> > }
> >
> > The fist reliable data channel will always be the first data
> > channel in reliable array.
> >
You don't need this method, DataChannel could be a Property and then you
get this via GetProperties().
--
Gustavo F. Padovan
http://padovan.org
next prev parent reply other threads:[~2010-07-08 19:17 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-07-08 17:12 Proposed API for HDP José Antonio Santos Cadenas
2010-07-08 17:39 ` Marcel Holtmann
2010-07-08 18:33 ` José Antonio Santos Cadenas
2010-07-08 19:15 ` Marcel Holtmann
2010-07-08 19:50 ` Santiago Carot-Nemesio
2010-07-08 19:17 ` Gustavo F. Padovan [this message]
2010-07-08 20:30 ` José Antonio Santos Cadenas
2010-07-08 17:54 ` Gustavo F. Padovan
2010-07-08 18:36 ` José Antonio Santos Cadenas
2010-07-08 19:13 ` Gustavo F. Padovan
2010-07-09 12:46 ` José Antonio Santos Cadenas
2010-07-09 13:49 ` José Antonio Santos Cadenas
2010-07-09 14:04 ` Elvis Pfützenreuter
2010-07-09 16:55 ` Gustavo F. Padovan
2010-07-09 17:12 ` José Antonio Santos Cadenas
2010-07-09 17:36 ` Gustavo F. Padovan
2010-07-09 18:13 ` Proposed API for HDP (v3) José Antonio Santos Cadenas
2010-07-09 18:39 ` Proposed API for HDP (v4) 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=20100708191755.GD26759@vigoh \
--to=gustavo@padovan.org \
--cc=linux-bluetooth@vger.kernel.org \
--cc=marcel@holtmann.org \
--cc=santoscadenas@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.