Hi Marcel,
Here is the first patch based on your last BlueZ D-Bus API document.
Let me know if you have some question/suggestion about
function/variable names, code standard, ...
Next actions:
1. Set/GetMode should use strings arguments
2. update python test script
3. Implement the missing services
Regards,
Claudio.
--
---------------------------------------------------------
Claudio Takahasi
Instituto Nokia de Tecnologia - INdT
Hi Claudio,
> Just to avoid code conflicts, I will start implement the
> discoverable/connectable functions.
go ahead. I have some other stuff to finish first.
> Eduardo told me that he can fix
> the dbus-test python script.
That would be great.
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
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel
Hi guys,
Just to avoid code conflicts, I will start implement the
discoverable/connectable functions. Eduardo told me that he can fix
the dbus-test python script.
Regards,
Claudio.
On 2/13/06, Marcel Holtmann <[email protected]> wrote:
> Hi Claudio,
>
> > 1. The functions get_device_name(hcitool.c) and
> > get_peer_name(dbus-device.c) does the same thing. We should move it to
> > a common file.
>
> not right now. The code duplication is that small that I have no
> problems with it and creating another internal library for it, is way
> too much overhead.
>
> > 2. The header file dbus.h intends to be a file used by D-Bus client
> > developers. There are some constants, type definition and function
> > prototypes that we could move to internal header file:
> > "dbus-internal.h" or split into separeted file(one for each .c file -
> > according with Johan's suggestion).
>
> I have no favor in any direction at the moment, but I don't think that
> we need a global dbus.h file for other C clients using the D-Bus
> interface. My understanding is that no client should depend on any code
> or headers provided by bluez-libs or bluez-utils. We will make a clean
> split with the D-Bus API. If this means that every client has some kind
> of duplication, so will be it.
>
> Regards
>
> Marcel
>
>
>
>
> -------------------------------------------------------
> This SF.net email is sponsored by: Splunk Inc. Do you grep through log fi=
les
> 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=3Dlnk&kid=3D103432&bid=3D230486&dat=
=3D121642
> _______________________________________________
> Bluez-devel mailing list
> [email protected]
> https://lists.sourceforge.net/lists/listinfo/bluez-devel
>
--
---------------------------------------------------------
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
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel
Hi Claudio,
> 1. The functions get_device_name(hcitool.c) and
> get_peer_name(dbus-device.c) does the same thing. We should move it to
> a common file.
not right now. The code duplication is that small that I have no
problems with it and creating another internal library for it, is way
too much overhead.
> 2. The header file dbus.h intends to be a file used by D-Bus client
> developers. There are some constants, type definition and function
> prototypes that we could move to internal header file:
> "dbus-internal.h" or split into separeted file(one for each .c file -
> according with Johan's suggestion).
I have no favor in any direction at the moment, but I don't think that
we need a global dbus.h file for other C clients using the D-Bus
interface. My understanding is that no client should depend on any code
or headers provided by bluez-libs or bluez-utils. We will make a clean
split with the D-Bus API. If this means that every client has some kind
of duplication, so will be it.
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
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel
Hi,
On 2/13/06, Johan Hedberg <[email protected]> wrote:
> Hi Marcel,
>
> On Sat, Feb 11, 2006, Marcel Holtmann wrote:
> > > Btw Marcel, the API document should probably be added to CVS or
> > > published on this list since AFAIK currently you, I, Claudio and Edua=
rdo
> > > 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 publi=
c
> > 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.
>
> > > > 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).
[Claudio Takahasi]
1. The functions get_device_name(hcitool.c) and
get_peer_name(dbus-device.c) does the same thing. We should move it to
a common file.
2. The header file dbus.h intends to be a file used by D-Bus client
developers. There are some constants, type definition and function
prototypes that we could move to internal header file:
"dbus-internal.h" or split into separeted file(one for each .c file -
according with Johan's suggestion).
Regards,
Claudio.
>
> Johan
>
>
> -------------------------------------------------------
> This SF.net email is sponsored by: Splunk Inc. Do you grep through log fi=
les
> 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=3Dlnk&kid=3D103432&bid=3D230486&dat=
=3D121642
> _______________________________________________
> Bluez-devel mailing list
> [email protected]
> https://lists.sourceforge.net/lists/listinfo/bluez-devel
>
--
---------------------------------------------------------
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
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel
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
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel
Hi Marcel,
On Sat, Feb 11, 2006, Marcel Holtmann wrote:
> > 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.
> > > 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).
Johan
-------------------------------------------------------
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
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel
Hi Johan,
> > wow. These are a lot of changes in one patch. I would personally prefer
> > to only get the Manager interface right at the moment and do the Device
> > interface stuff after that. However it might make sense to do a clean
> > cut and apply this patch and then start from there.
> >
> > Johan, what do you think?
>
> Well, it is a big patch. However, while it would be easier to follow if
> it was split into several parts (e.g. manager, discovery, bonding, etc),
> we need to get most things in the new API document commited anyway
> before next release, so I don't have anything against applying Claudio's
> patch and continuing work from there.
it is in the CVS now. Let's be maverick :)
> 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.
> > 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?
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
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel
Hi Claudio,
> Sorry, I found a small bug :)
> I forgot remove a unused function.
and you forgot to declare the ...bonding_created... function correctly.
This is fixed and applied to the CVS. Watch out for compiler warnings,
because in most cases they wanna tell you something :)
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
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel
Hi Marcel,
On Fri, Feb 10, 2006, Marcel Holtmann wrote:
> wow. These are a lot of changes in one patch. I would personally prefer
> to only get the Manager interface right at the moment and do the Device
> interface stuff after that. However it might make sense to do a clean
> cut and apply this patch and then start from there.
>
> Johan, what do you think?
Well, it is a big patch. However, while it would be easier to follow if
it was split into several parts (e.g. manager, discovery, bonding, etc),
we need to get most things in the new API document commited anyway
before next release, so I don't have anything against applying Claudio's
patch and continuing work from there.
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.
> 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).
Johan
-------------------------------------------------------
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
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel
Hi Claudio,
> Maybe we should put the error functions in a separated file too.
feel free to propose something.
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
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel
Hi Marcel,
Sorry, I found a small bug :)
I forgot remove a unused function.
Maybe we should put the error functions in a separated file too.
Regards,
Claudio.
On 2/10/06, Marcel Holtmann <[email protected]> wrote:
> Hi Claudio,
>
> > Here is the first patch based on your last BlueZ D-Bus API document.
> >
> > Let me know if you have some question/suggestion about
> > function/variable names, code standard, ...
>
> wow. These are a lot of changes in one patch. I would personally prefer
> to only get the Manager interface right at the moment and do the Device
> interface stuff after that. However it might make sense to do a clean
> cut and apply this patch and then start from there.
>
> Johan, what do you think?
>
> Should we split the Manager interface and the Device interface into two
> separate files?
>
> 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
> [email protected]
> https://lists.sourceforge.net/lists/listinfo/bluez-devel
>
--
---------------------------------------------------------
Claudio Takahasi
Instituto Nokia de Tecnologia - INdT
Hi Claudio,
> Here is the first patch based on your last BlueZ D-Bus API document.
>
> Let me know if you have some question/suggestion about
> function/variable names, code standard, ...
wow. These are a lot of changes in one patch. I would personally prefer
to only get the Manager interface right at the moment and do the Device
interface stuff after that. However it might make sense to do a clean
cut and apply this patch and then start from there.
Johan, what do you think?
Should we split the Manager interface and the Device interface into two
separate files?
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
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel