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 --]
next prev parent 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 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.