From: Marcel Holtmann <marcel@holtmann.org>
To: bluez-devel@lists.sourceforge.net
Subject: Re: [Bluez-devel] [DBUS PATCH] BlueZ D-Bus redesign
Date: Mon, 13 Feb 2006 09:03:22 +0100 [thread overview]
Message-ID: <1139817802.31372.11.camel@localhost> (raw)
In-Reply-To: <20060213073021.GA29708@localhost.localdomain>
Hi Johan,
> > > Btw Marcel, the API document should probably be added to CVS or
> > > published on this list since AFAIK currently you, I, Claudio and Eduardo
> > > are the only ones in posession of it.
> >
> > Actually I wanted to wait until it is in a better shape, but since they
> > mentioned it several times on the mailing list, we should make it public
> > anyway. Please do a last review and then I commit it to the CVS.
>
> I don't have currently any big issues with it. One thing we may want to
> add to it in the future is descriptions of the different types of errors
> that the methods can return.
and I am thinking of re-designing the errors. Once you deal with
languages like C# or Java, you might wanna have clear exceptions.
However we need an updated dbus-test script. Can someone please address
this.
> > > > Should we split the Manager interface and the Device interface into two
> > > > separate files?
> > >
> > > I think that would make sense. That way you could also define clearer
> > > interfaces between them in the code (function wise).
> >
> > Any proposals on how we gonna do the split?
>
> I see you've already made the split in CVS, and it looks ok. I'd
> probably split the dbus.h file also into separate files (one for each .c
> file). At some point we might also need a "dbus-common.c" file for
> common helper functions (e.g. the client lifetime tracking may be one
> thing that could go into it).
The split is not perfect, because we have overlaps for that I had to
introduce some ugly hacks to get them working. However the current split
makes it a little bit easier to work with the code. I also introduced
some generic device handling. In the end this layer should take care of
the inquiry cache and the connection tracking.
The Manager part should work now as expected, but I had some small race
condition with the BD_ADDR. So I think we send the DeviceAdded signal a
little bit too soon. I worked around it with re-reading the address if
it hasn't been set correctly.
Does anybody know how to receive D-Bus signals within C#? I started to
write some bluetooth-sharp bindings for the BlueZ D-Bus API, but I can't
find any documentation on how to deal with the signals. The methods
stuff is working perfect.
Regards
Marcel
-------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems? Stop! Download the new AJAX search engine that makes
searching your log files as easy as surfing the web. DOWNLOAD SPLUNK!
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=103432&bid=230486&dat=121642
_______________________________________________
Bluez-devel mailing list
Bluez-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bluez-devel
next prev parent reply other threads:[~2006-02-13 8:03 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2006-02-10 18:29 [Bluez-devel] [DBUS PATCH] BlueZ D-Bus redesign Claudio Takahasi
2006-02-10 18:40 ` Marcel Holtmann
2006-02-10 18:53 ` Claudio Takahasi
2006-02-10 19:46 ` Marcel Holtmann
2006-02-11 3:52 ` Marcel Holtmann
2006-02-10 23:00 ` Johan Hedberg
2006-02-11 3:55 ` Marcel Holtmann
2006-02-13 7:30 ` Johan Hedberg
2006-02-13 8:03 ` Marcel Holtmann [this message]
2006-02-13 12:44 ` Claudio Takahasi
2006-02-13 12:51 ` Marcel Holtmann
2006-02-13 13:37 ` Claudio Takahasi
2006-02-13 14:16 ` 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=1139817802.31372.11.camel@localhost \
--to=marcel@holtmann.org \
--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).