Linux bluetooth development
 help / color / mirror / Atom feed
From: Marcel Holtmann <marcel@holtmann.org>
To: Mikel Astiz <mikel.astiz.oss@gmail.com>
Cc: Patrick Ohly <patrick.ohly@intel.com>, linux-bluetooth@vger.kernel.org
Subject: Re: [PATCH obexd v0] client-doc: Guarantee prefix in transfer paths
Date: Tue, 21 Aug 2012 14:08:43 +0200	[thread overview]
Message-ID: <1345550923.13726.84.camel@aeonflux> (raw)
In-Reply-To: <CANT-zCV9exkSjQhvGqLVqdBL+GBvNG97EUnPGo55_AaAO60P+A@mail.gmail.com>

Hi Mikel,

> >> The client D-Bus documentation should mention that all transfer paths
> >> contain a prefix consisting of the path of the session they belong to.
> >>
> >> This can be conveniently used by clients to install D-Bus signal matches
> >> that concentrate on the relevant signals.
> >> ---
> >>  doc/client-api.txt |    2 +-
> >>  1 files changed, 1 insertions(+), 1 deletions(-)
> >>
> >> diff --git a/doc/client-api.txt b/doc/client-api.txt
> >> index 839a78c..7ca65cc 100644
> >> --- a/doc/client-api.txt
> >> +++ b/doc/client-api.txt
> >> @@ -466,7 +466,7 @@ Transfer hierarchy
> >>
> >>  Service              org.bluez.obex.client
> >>  Interface    org.bluez.obex.Transfer
> >> -Object path  [variable prefix]/{transfer0,transfer1,...}
> >> +Object path  [variable prefix]/{session0,session1,...}/{transfer0,...}
> >>
> >>  Methods              dict GetProperties()
> >
> > It would be even better to explicitly mention that the "[variable
> > prefix]" here is the same as the "[variable prefix]" in the Session.
> 
> This documentation pattern can be widely found in Obexd and Bluez, as
> well as oFono. It's implicit that the variable prefix matches in both
> cases.

it actually means that you can not count on this prefix. It might change
and it is perfect legal that it changes from one run of the daemon to
another. The variable prefix is discovered via some defined initial
method.

Remember that I intermixed the PID in the object path of BlueZ. Simple
because people started hardcoding object paths.

Regards

Marcel



  reply	other threads:[~2012-08-21 12:08 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-08-21  7:23 [PATCH obexd v0] client-doc: Guarantee prefix in transfer paths Mikel Astiz
2012-08-21  8:31 ` Patrick Ohly
2012-08-21 11:41   ` Mikel Astiz
2012-08-21 12:08     ` Marcel Holtmann [this message]
2012-08-21 12:15       ` Mikel Astiz
2012-08-22 11:39   ` Luiz Augusto von Dentz
2012-08-22 12:04     ` Patrick Ohly
2012-08-22 12:42       ` Mikel Astiz
2012-08-22 12:52       ` Luiz Augusto von Dentz
2012-08-22 16:19         ` Patrick Ohly
2012-08-27  7:00 ` Luiz Augusto von Dentz

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=1345550923.13726.84.camel@aeonflux \
    --to=marcel@holtmann.org \
    --cc=linux-bluetooth@vger.kernel.org \
    --cc=mikel.astiz.oss@gmail.com \
    --cc=patrick.ohly@intel.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox