[Bluez-devel] D-Bus tasks planning

[Bluez-devel] D-Bus tasks planning

[Claudio Takahasi]

Hi guys,

I've just started planning the activities for this year. I would like
receive feedbacks/comments about the items below. There are some tasks
suggested and a lot of clouds :)  I consider these tasks essential to
make the D-Bus services usable and necessary to start the development
of Network, Serial, HID, ... services over D-Bus.

* Move hcid to bluetoothd

* BlueZ SDP D-Bus
    - How design it?  According with an old discussion, the SDP should
be implemented inside the bluetoothd completelly, because this gives
the possibility of SDP record caching. Considering this assumption,
what are the drawbacks and the side-effects to the current
applications?

* Kernel/Userspace communication interface
    - kernel inquiry cache. At the momment, one important enhancement
is provide a easy access and non-blocking inquiry operation.
    - probably this communication interface will be usefull to avoid
another blocking operations. eg: connection control stuffs.


Others planned tasks:
* Continue GBlueZConf: Check Gnome UI guidelines, create CVS
repository, support for local adapter setup, ...
* Force authentication: Make possible re-pairing.
* Remote Name: use text file stored data to solve instead of use LMP
command for every request.


Regards,
Claudio.

--
---------------------------------------------------------
Claudio Takahasi
Instituto Nokia de Tecnologia - INdT


-------------------------------------------------------
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

Re: [Bluez-devel] D-Bus tasks planning

[Marcel Holtmann]

Hi Claudio,

> I've just started planning the activities for this year. I would like
> receive feedbacks/comments about the items below. There are some tasks
> suggested and a lot of clouds :)  I consider these tasks essential to
> make the D-Bus services usable and necessary to start the development
> of Network, Serial, HID, ... services over D-Bus.
> 
> * Move hcid to bluetoothd

since I don't wanna use threads, we need a good and safe event loop
implementation that integrates nicely with D-Bus. The one from Glib is
no option.

> * BlueZ SDP D-Bus
>     - How design it?  According with an old discussion, the SDP should
> be implemented inside the bluetoothd completelly, because this gives
> the possibility of SDP record caching. Considering this assumption,
> what are the drawbacks and the side-effects to the current
> applications?

The problem with the current SDP API is that it is blocking and at some
places really horrible. We need an event driven API and if we don't
wanna use threads, we have to rewrite it.

> * Kernel/Userspace communication interface
>     - kernel inquiry cache. At the momment, one important enhancement
> is provide a easy access and non-blocking inquiry operation.
>     - probably this communication interface will be usefull to avoid
> another blocking operations. eg: connection control stuffs.

The first thing is to fully implement the kernel internal security
manager and make the new bluetoothd handle the PIN code and link key
requests/notification send over this new interface.

At the moment we do that all inside hcid in userspace. It works great,
but the code to keep track of new devices etc. is not really what I like
to have in the future. It is actually not bad, but why should we do it
inside the kernel and again outside the kernel. The kernel HCI layer is
already capable of handling all the tasks of tracking HCI message flow.
We only need to define a nice interface to give the userspace access to
this information.

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

Re: [Bluez-devel] D-Bus tasks planning

[P. Durante]

Hi there,
I'm happy to see the DBus issue again on the list.
Even if I've already been told you don't like c++, I've got some code
which does exactly what you're looking for so maybe it may be of some
use, unfortunately I'm a student and
this leaves me with little for fun activities (like coding) so the
code hasn't been touched for a while(=3Dmonths), I've started a complete
rewrite but I don't know how long this is going to take, in the
meantime I hope the old version will be useful, at least to grab some
ideas

>
> The problem with the current SDP API is that it is blocking and at some
> places really horrible. We need an event driven API and if we don't
> wanna use threads, we have to rewrite it.
>
sdp api:
http://svn.berlios.de/viewcvs/bluetool/trunk/lib/bluetool/include/bluetool/=
sdpclient.h?view=3Dmarkup
http://svn.berlios.de/viewcvs/bluetool/trunk/lib/bluetool/src/linux/sdpclie=
nt.cpp?view=3Dmarkup

http://svn.berlios.de/viewcvs/bluetool/trunk/lib/bluetool/include/bluetool/=
sdprecord.h?view=3Dmarkup
http://svn.berlios.de/viewcvs/bluetool/trunk/lib/bluetool/src/linux/sdpreco=
rd.cpp?view=3Dmarkup
http://svn.berlios.de/viewcvs/bluetool/trunk/lib/bluetool/src/linux/sdpreco=
rd_p.h?view=3Dmarkup

http://svn.berlios.de/viewcvs/bluetool/trunk/lib/bluetool/include/bluetool/=
sdperror.h?view=3Dmarkup
http://svn.berlios.de/viewcvs/bluetool/trunk/lib/bluetool/src/linux/sdperro=
r.cpp?view=3Dmarkup

glue between the sdp api and dbus:
http://svn.berlios.de/viewcvs/bluetool/trunk/bin/daemon/src/sdp/sdp_browser=
.h?view=3Dmarkup
http://svn.berlios.de/viewcvs/bluetool/trunk/bin/daemon/src/sdp/sdp_browser=
.cpp?view=3Dmarkup

http://svn.berlios.de/viewcvs/bluetool/trunk/bin/daemon/src/sdp/sdp_record.=
h?view=3Dmarkup
http://svn.berlios.de/viewcvs/bluetool/trunk/bin/daemon/src/sdp/sdp_record.=
cpp?view=3Dmarkup

>
> since I don't wanna use threads, we need a good and safe event loop
> implementation that integrates nicely with D-Bus. The one from Glib is
> no option.
>
I've got an alternative which does not depend on glib (in the same
repository) but it's not very clean and safe so I'll spare you the
horror :-)

regards,
Paul


-------------------------------------------------------
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

Re: [Bluez-devel] D-Bus tasks planning

[Marcel Holtmann]

Hi Paul,

> I'm happy to see the DBus issue again on the list.
> Even if I've already been told you don't like c++, I've got some code
> which does exactly what you're looking for so maybe it may be of some
> use, unfortunately I'm a student and
> this leaves me with little for fun activities (like coding) so the
> code hasn't been touched for a while(=months), I've started a complete
> rewrite but I don't know how long this is going to take, in the
> meantime I hope the old version will be useful, at least to grab some
> ideas

using C++ for hcid or bluetoothd is no option, but for the clients that
communicate over D-Bus, I don't care. Make them use C++, Mono/C# or
whatever language binding is supported by D-Bus.

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

Re: [Bluez-devel] D-Bus tasks planning

[Charles Bueche]

On mar, 2006-01-17 at 14:49 +0100, Marcel Holtmann wrote:
> Hi Claudio,
> 
> > I've just started planning the activities for this year. I would like
> > receive feedbacks/comments about the items below. There are some tasks
> > suggested and a lot of clouds :)  I consider these tasks essential to
> > make the D-Bus services usable and necessary to start the development
> > of Network, Serial, HID, ... services over D-Bus.
> > 
> > * Move hcid to bluetoothd
> 
> since I don't wanna use threads, 
...

Hi,

I'm not knowledgeable about threads in C and within bluez, but during my
projects in Perl, I have found them a valuable asset. For my curiosity,
what are the reasons behind your decision ?

Not that I would suggest you to use them, you have probably good reasons
behind the decision.

Charles



-------------------------------------------------------
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

Re: [Bluez-devel] D-Bus tasks planning

[Marcel Holtmann]

Hi Charles,

> > > I've just started planning the activities for this year. I would like
> > > receive feedbacks/comments about the items below. There are some tasks
> > > suggested and a lot of clouds :)  I consider these tasks essential to
> > > make the D-Bus services usable and necessary to start the development
> > > of Network, Serial, HID, ... services over D-Bus.
> > > 
> > > * Move hcid to bluetoothd
> > 
> > since I don't wanna use threads, 
> ...
> 
> I'm not knowledgeable about threads in C and within bluez, but during my
> projects in Perl, I have found them a valuable asset. For my curiosity,
> what are the reasons behind your decision ?

since the bluetoothd should also run on any embedded system, it is a
good idea to not use thread, because they might not be as portable as an
event loop.

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

Re: [Bluez-devel] D-Bus tasks planning

[Charles Bueche]

On mer, 2006-01-18 at 14:18 +0100, Marcel Holtmann wrote:
> Hi Charles,
> 
> > > > I've just started planning the activities for this year. I would like
> > > > receive feedbacks/comments about the items below. There are some tasks
> > > > suggested and a lot of clouds :)  I consider these tasks essential to
> > > > make the D-Bus services usable and necessary to start the development
> > > > of Network, Serial, HID, ... services over D-Bus.
> > > > 
> > > > * Move hcid to bluetoothd
> > > 
> > > since I don't wanna use threads, 
> > ...
> > 
> > I'm not knowledgeable about threads in C and within bluez, but during my
> > projects in Perl, I have found them a valuable asset. For my curiosity,
> > what are the reasons behind your decision ?
> 
> since the bluetoothd should also run on any embedded system, it is a
> good idea to not use thread, because they might not be as portable as an
> event loop.

this is a very good reason, I didn't think about embedded systems.

OT : around 1990, I have been developing software for embedded systems
as well, and I can remember it was good fun. We had to work with stuff
like vrtx, so not much opensource/Linux nor TCP/IP, but it was a good
time anyway. Then, I switched to Sun sysadmin. The two areas are merging
again :-)

Charles



-------------------------------------------------------
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