linux-bluetooth.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Claudio Takahasi <cktakahasi@gmail.com>
To: bluez-devel@lists.sourceforge.net
Subject: Re: [Bluez-devel] D-Bus patching session opened
Date: Thu, 22 Sep 2005 16:13:33 -0300	[thread overview]
Message-ID: <e1effdeb0509221213392b9976@mail.gmail.com> (raw)
In-Reply-To: <1127399305.5344.36.camel@blade>

[-- Attachment #1: Type: text/plain, Size: 3455 bytes --]

Hi Marcel,

I have some comments and questions:

1. Multiple bluetooth adapters
This is an old discussion but we didn't written it in a stone.
Do you plan support address multiple local adapter or not?
If yes, we have to plan how define the object path. My suggestion
is insert the device id in the path(org/bluez/dev_id/hci,
org/bluez/dev_id/pan, ...).

2. Non D-Bus systems
You wrote in an old email: "bluetoothd should combine hcid and sdpd".
I didn't understand the scope of this assertion. IMHO in the future
for D-Bus enable systems bluetoothd should provide hcid, sdpd and
profiles services(D-Bus).
hcid features include control initialize/register) adapters and
provide D-Bus services for get adapter infos and basic task like
inquiry, scan, remote name, ..
sdpd services include register/unregister local services, control
incomming connections and D-Bus services for search services.
Regarding sdp services, is it necessary provide a D-Bus service for
register/unregister services or we have to use sdp_connect +
sdp_device_record_register?

As long as I could understand, bluetoothd will not be only a
D-Bus service provider, but it must support NON D-Bus clients too.
Is that correct?

3. API version
We have to think how keep the backward compatibility among
the future BlueZ D-Bus services versions. I my opinion we have three
options:
- create a initialization service for bluetoothd where we
can check the version.
- insert an extra arguments in each method call(request)
- define different interface name based on the API version

4. Introspect
It's becomming common implement a Introspectable interface that
make possible get a xml string describing the provided services.
It can be a good feature support it.



Regards,
Claudio

On 9/22/05, Marcel Holtmann <marcel@holtmann.org> wrote:
>
> Hi,
>
> after I dropped the D-Bus 0.23 API support it is now time to really play
> with the integration of D-Bus support into hcid and other daemons. This
> is the first step into creating a full D-Bus aware bluetoothd in the
> future.
>
> I like to see some more D-Bus enhancements now and Claudio already
> started and he's working hard in explaining his work and making me
> happy. So please help him and review his code and send small patches to
> make the D-Bus experience better. I think about making the D-Bus a core
> dependency of bluez-utils. Does anybody have any arguments against it?
>
> Next thing that I like to see are some Python applications that are
> using GTK+ and D-Bus for a graphical interface to BlueZ. For that I
> think about creating a bluez-python package. Therefor we need people who
> are writing the code and other people who are creating some nice fancy
> icons and graphics for it. First thing should be a D-Bus aware PIN
> helper written completely in Python.
>
> There exists a job/task for everyone :)
>
> Regards
>
> Marcel
>
>
>
>
> -------------------------------------------------------
> SF.Net email is sponsored by:
> Tame your development challenges with Apache's Geronimo App Server.
> Download it for free - -and be entered to win a 42" plasma tv or your very
> own Sony(tm)PSP. Click here to play: http://sourceforge.net/geronimo.php
> _______________________________________________
> Bluez-devel mailing list
> Bluez-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bluez-devel
>

[-- Attachment #2: Type: text/html, Size: 4181 bytes --]

  reply	other threads:[~2005-09-22 19:13 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2005-09-22 14:28 [Bluez-devel] D-Bus patching session opened Marcel Holtmann
2005-09-22 19:13 ` Claudio Takahasi [this message]
2005-09-22 19:55   ` Marcel Holtmann

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=e1effdeb0509221213392b9976@mail.gmail.com \
    --to=cktakahasi@gmail.com \
    --cc=bluez-devel@lists.sourceforge.net \
    /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;
as well as URLs for NNTP newsgroup(s).