[Bluez-devel] Announce : BlueZ-based implemantation of JSR82

[Bluez-devel] Announce : BlueZ-based implemantation of JSR82

[Julien Campana]

Hi,

We have developped a JSR-82 implementation for Linux, which is based on
BlueZ and which is compatible with most USB-Dongle's.

We've used parts of JavaBluetooth.org's works and parts of JBluez's
stuff.
The native C-Code of the project is entirely based on the BlueZ project
and I would like to thanks Marcel Holtmann for his answers to my
questions, which were all helpfull.

We've decided to make the Linux version OpenSource. 

The JSR-82 specification is not yet fully implemented but the major part
of the work (let say 95%) is done.

The package can be downloaded at the following address:
http://www.avetana-gmbh.de/avetana-gmbh/jsr82.xml

The web site is in german but will be soon translated in english. 

JSR-82 is a Sun Microsystems specification for easily developping
bluetooth based application in Java. 
Good tutorials can be found on the Java developper Center web site as
well as on manay other web sites.
For more information about JSR-82, please consult the site:
http://www.jcp.org/en/jsr/detail?id=82

Julien Campana,

-------------
Avetana GmbH
Julien Campana - CTO
Beiertheimer Allee 58
D-76137 Karlsruhe
E-mail: julien.campana@avetana.de
Web: http://www.avetana.de




-------------------------------------------------------
This SF.Net email is sponsored by: Oracle 10g
Get certified on the hottest thing ever to hit the market... Oracle 10g. 
Take an Oracle 10g class now, and we'll give you the exam FREE.
http://ads.osdn.com/?ad_id=3149&alloc_id=8166&op=click
_______________________________________________
Bluez-devel mailing list
Bluez-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bluez-devel

Re: [Bluez-devel] Announce : BlueZ-based implemantation of JSR82

[Mauro Tortonesi]

On Monday 24 May 2004 12:07, Julien Campana wrote:
> Hi,
>
> We have developped a JSR-82 implementation for Linux, which is based on
> BlueZ and which is compatible with most USB-Dongle's.
>
> We've used parts of JavaBluetooth.org's works and parts of JBluez's
> stuff.
> The native C-Code of the project is entirely based on the BlueZ project
> and I would like to thanks Marcel Holtmann for his answers to my
> questions, which were all helpfull.
>
> We've decided to make the Linux version OpenSource.
>
> The JSR-82 specification is not yet fully implemented but the major part
> of the work (let say 95%) is done.
>
> The package can be downloaded at the following address:
> http://www.avetana-gmbh.de/avetana-gmbh/jsr82.xml
>
> The web site is in german but will be soon translated in english.
>
> JSR-82 is a Sun Microsystems specification for easily developping
> bluetooth based application in Java.
> Good tutorials can be found on the Java developper Center web site as
> well as on manay other web sites.
> For more information about JSR-82, please consult the site:
> http://www.jcp.org/en/jsr/detail?id=82

hi julien and all,

i am working on a similar project (also derived from javabluetooth), a jsr82 
implementation based on bluez that supports also SCO and ASB logical 
transports:

http://lia.deis.unibo.it/Research/ubiQoS/audioStreaming/

perhaps we could cooperate somehow?

-- 
Aequam memento rebus in arduis servare mentem...

Mauro Tortonesi                 mtortonesi@ing.unife.it
                                mauro@deepspace6.net
                                mauro@ferrara.linux.it
Deep Space 6 - IPv6 with Linux  http://www.deepspace6.net
Ferrara Linux User Group        http://www.ferrara.linux.it




-------------------------------------------------------
This SF.Net email is sponsored by: Oracle 10g
Get certified on the hottest thing ever to hit the market... Oracle 10g. 
Take an Oracle 10g class now, and we'll give you the exam FREE.
http://ads.osdn.com/?ad_id=3149&alloc_id=8166&op=click
_______________________________________________
Bluez-devel mailing list
Bluez-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bluez-devel

Re: [Bluez-devel] Announce : BlueZ-based implemantation of JSR82

[Marcel Holtmann]

Hi Julien,

> We have developped a JSR-82 implementation for Linux, which is based on
> BlueZ and which is compatible with most USB-Dongle's.
> 
> We've used parts of JavaBluetooth.org's works and parts of JBluez's
> stuff.
> The native C-Code of the project is entirely based on the BlueZ project
> and I would like to thanks Marcel Holtmann for his answers to my
> questions, which were all helpfull.

you are welcome.

> We've decided to make the Linux version OpenSource. 
> 
> The JSR-82 specification is not yet fully implemented but the major part
> of the work (let say 95%) is done.

I would never use Java for Bluetooth programming, but it seems that some
companies wants this, especially mobile phone manufacturers. So I think
we should build up a clean implementation of the JSR-82 standard that
uses BlueZ as underlying Bluetooth stack. Clean means for me that we
should concentrate on BlueZ and try to interface BlueZ<->JSR-82 as best
as possible. Give me some comments if there is really interest in doing
this.

Regards

Marcel




-------------------------------------------------------
This SF.Net email is sponsored by: Oracle 10g
Get certified on the hottest thing ever to hit the market... Oracle 10g. 
Take an Oracle 10g class now, and we'll give you the exam FREE.
http://ads.osdn.com/?ad_id=3149&alloc_id=8166&op=click
_______________________________________________
Bluez-devel mailing list
Bluez-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bluez-devel

Re: [Bluez-devel] Announce : BlueZ-based implemantation of JSR82

[Julien Campana]

Am Di, den 25.05.2004 schrieb Marcel Holtmann um 14:14:
> Hi Julien,
> 
> > We have developped a JSR-82 implementation for Linux, which is based on
> > BlueZ and which is compatible with most USB-Dongle's.
> > 
> > We've used parts of JavaBluetooth.org's works and parts of JBluez's
> > stuff.
> > The native C-Code of the project is entirely based on the BlueZ project
> > and I would like to thanks Marcel Holtmann for his answers to my
> > questions, which were all helpfull.
> 
> you are welcome.
> 
> > We've decided to make the Linux version OpenSource. 
> > 
> > The JSR-82 specification is not yet fully implemented but the major part
> > of the work (let say 95%) is done.
> 
> I would never use Java for Bluetooth programming, but it seems that some
> companies wants this, especially mobile phone manufacturers. So I think
> we should build up a clean implementation of the JSR-82 standard that
> uses BlueZ as underlying Bluetooth stack.

This is exactly what I did, or at least I have implemented a big part of
the JSR-82 Standard with BlueZ as underlying Bluetooth stack. (I suppose
but do not really know if the implementation is clean:)). If you want
this implementation to be part of the BlueZ project, I (and especially
my boss:) agree.

>  Clean means for me that we
> should concentrate on BlueZ and try to interface BlueZ<->JSR-82 as best
> as possible. 

To better understand the way I have interfaced BlueZ <->JSR-82 and if
you have enough time for this, I invite you to have a quick look at the
file sources/c/BlueZ.cpp contained in the tgz archive downloadable at
http://www.avetana-gmbh.de/avetana-gmbh/jsr82.xml

This c file mostly re-write some BlueZ method and has surely to be
cleaned and documented. 
This will be the next step of my work. This version is still a
beta-version but is stable and robust enough to be used in a project.
especially if the project uses RFCOMM connections. (there is still some
work to do with L2CAP).

> Give me some comments if there is really interest in doing
> this.

I will continue to work on this project until I reach a clean and really
stable implementation. If you have any comment about the implementation
do not hesitate to mail me. 

Regards,

Julien

> Regards
> 
> Marcel
> 

[Bluez-devel] Flush timeout at Baseband

[Wang Haiguang]

Hi, all.

It seems that the current implementaion of "hciconfig" does not support the
"flush timeout" configuration for ACL data. 

Is there any plan on it as it is important for the real-time traffic?. 

According to the specification, the default value is infinite. 

Best regards.

Haiguang 


-------------------------------------------------------
This SF.Net email is sponsored by: Oracle 10g
Get certified on the hottest thing ever to hit the market... Oracle 10g. 
Take an Oracle 10g class now, and we'll give you the exam FREE.
http://ads.osdn.com/?ad_id=3149&alloc_id=8166&op=click
_______________________________________________
Bluez-devel mailing list
Bluez-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bluez-devel

Re: [Bluez-devel] Flush timeout at Baseband

[Marcel Holtmann]

Hi Haiguang,

> It seems that the current implementaion of "hciconfig" does not support the
> "flush timeout" configuration for ACL data. 
> 
> Is there any plan on it as it is important for the real-time traffic?. 
> 
> According to the specification, the default value is infinite. 

I don't had a need to touch the flush timeout value. About what HCI
command to modify the flush timeout are you talking? If you talk about
QoS then there is room in our code to fill.

Regards

Marcel




-------------------------------------------------------
This SF.Net email is sponsored by: Oracle 10g
Get certified on the hottest thing ever to hit the market... Oracle 10g. 
Take an Oracle 10g class now, and we'll give you the exam FREE.
http://ads.osdn.com/?ad_id=3149&alloc_id=8166&op=click
_______________________________________________
Bluez-devel mailing list
Bluez-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bluez-devel

Re: [Bluez-devel] Announce : BlueZ-based implemantation of JSR82

[Marcel Holtmann]

Hi Julien,

> > I would never use Java for Bluetooth programming, but it seems that some
> > companies wants this, especially mobile phone manufacturers. So I think
> > we should build up a clean implementation of the JSR-82 standard that
> > uses BlueZ as underlying Bluetooth stack.
> 
> This is exactly what I did, or at least I have implemented a big part of
> the JSR-82 Standard with BlueZ as underlying Bluetooth stack. (I suppose
> but do not really know if the implementation is clean:)). If you want
> this implementation to be part of the BlueZ project, I (and especially
> my boss:) agree.

it is not, because as you mention later that you have to copy or rewrite
some of the BlueZ functions to fulfil the need for JSR-82. We should
talk about that and see what we can fixup in BlueZ.

What I also don't wanna use is somekind of "de.avetana.bluetooth" vendor
extensions. If something is not possible in pure Java JSR-82, sorry not
my bad ;)

And another important point for me is the coding style. The use of tabs
(8 spaces) is a must, because it makes the code easier to read and keep
developers from over-nesting.

> To better understand the way I have interfaced BlueZ <->JSR-82 and if
> you have enough time for this, I invite you to have a quick look at the
> file sources/c/BlueZ.cpp contained in the tgz archive downloadable at
> http://www.avetana-gmbh.de/avetana-gmbh/jsr82.xml
> 
> This c file mostly re-write some BlueZ method and has surely to be
> cleaned and documented. 
> This will be the next step of my work. This version is still a
> beta-version but is stable and robust enough to be used in a project.
> especially if the project uses RFCOMM connections. (there is still some
> work to do with L2CAP).

The native interface should only be a wrapper. Let's talk about the
stuff and put some of it back to the Bluetooth library where it should
belong.

> > Give me some comments if there is really interest in doing
> > this.
> 
> I will continue to work on this project until I reach a clean and really
> stable implementation. If you have any comment about the implementation
> do not hesitate to mail me. 

I know Java and I did a lot of programming with Java in the past, but I
haven't done anything in the last 5 years. May you write a small howto
for getting your stuff run. For me preferable with Debian Sid.

Regards

Marcel




-------------------------------------------------------
This SF.Net email is sponsored by: Oracle 10g
Get certified on the hottest thing ever to hit the market... Oracle 10g. 
Take an Oracle 10g class now, and we'll give you the exam FREE.
http://ads.osdn.com/?ad_id=3149&alloc_id=8166&op=click
_______________________________________________
Bluez-devel mailing list
Bluez-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bluez-devel

Re: [Bluez-devel] Announce : BlueZ-based implemantation of JSR82

[Marcel Holtmann]

Hi Julien,

> There are main reason why I rewrote some BlueZ functions is that:
> - Functions like "sdp_service_search_attr_req" return a list of
> sdp_record_t. If I had to parse these sdp_record_t  in order to
> construct the requested Java Objects, this would have been an amazing
> amount of switch or if statement. The best solution was therefore to
> directly send the bytes to the java implementation.

put this problem up in a seperate thread on the mailing list and tell
how the Java Objects have to look like. We should find a better solution
for that.

> > What I also don't wanna use is somekind of "de.avetana.bluetooth" vendor
> > extensions. If something is not possible in pure Java JSR-82, sorry not
> > my bad ;)
> 
> JSR-82 provides just the minimal amount of classes. It lets the
> programmer use "background classes" but this is transparent for the
> end-user (I will give some example of this transparency in the future
> how-to). These de.avetana.bluetooth.* classes are really needed to fully
> implement all javax.bluetooth.* classes.

You must explain this to me in detail, because I don't understand why.
Actually I think we should avoid this.

> > The native interface should only be a wrapper. Let's talk about the
> > stuff and put some of it back to the Bluetooth library where it should
> > belong.
> 
> I would say that 90% of the native interface is today a wrapper. Only
> the service search uses home-made-functions derived from the BlueZ code.

As said already, lets fix this in the Bluetooth library itself. I know
that SDP itself is a horrible mess of object oriented stuff, but I think
we will find a solution for it.

Regards

Marcel




-------------------------------------------------------
This SF.Net email is sponsored by: Oracle 10g
Get certified on the hottest thing ever to hit the market... Oracle 10g. 
Take an Oracle 10g class now, and we'll give you the exam FREE.
http://ads.osdn.com/?ad_id=3149&alloc_id=8166&op=click
_______________________________________________
Bluez-devel mailing list
Bluez-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bluez-devel

Re: [Bluez-devel] Announce : BlueZ-based implemantation of JSR82

[Julien Campana]

Am Di, den 25.05.2004 schrieb Marcel Holtmann um 17:07:
> Hi Julien,

Hi Marcel,

> 
> > There are main reason why I rewrote some BlueZ functions is that:
> > - Functions like "sdp_service_search_attr_req" return a list of
> > sdp_record_t. If I had to parse these sdp_record_t  in order to
> > construct the requested Java Objects, this would have been an amazing
> > amount of switch or if statement. The best solution was therefore to
> > directly send the bytes to the java implementation.
> 
> put this problem up in a seperate thread on the mailing list and tell
> how the Java Objects have to look like. We should find a better solution
> for that.

I will post this today or tomorrow. Furthermore, I will provide the
HOW-TO help file next week (sorry for the delay, but I currently have a
lot of work to do!). 


> > > What I also don't wanna use is somekind of "de.avetana.bluetooth" vendor
> > > extensions. If something is not possible in pure Java JSR-82, sorry not
> > > my bad ;)
> > 
> > JSR-82 provides just the minimal amount of classes. It lets the
> > programmer use "background classes" but this is transparent for the
> > end-user (I will give some example of this transparency in the future
> > how-to). These de.avetana.bluetooth.* classes are really needed to fully
> > implement all javax.bluetooth.* classes.
> 
> You must explain this to me in detail, because I don't understand why.
> Actually I think we should avoid this.

In order to explain this, I will take an example:
JSR-82 provides an interface called ServiceRecord. The role of the class
could be compared with the role of the sdp_record_t of BlueZ: storing
attributes and related DataElements. 
But no implementation of ServiceRecord is provided, it is just an
interface. 
Moreover, a look at the description of some JSR82 methods like
LocalDevice.getRecord() shows that two kinds of ServiceRecord are
needed: a "local" ServiceRecord and a "remote" ServiceRecord. This two
ServiceRecord must differ (for example, the "local" Service Record does
not implement some methods like getConnectionURL()). 
That's why I had to provide two different implementation of
ServiceRecord (LocalServiceRecord and RemoteServiceRecord). 
But if you use the javax.bluetooth.* api, you will mostly manipulate
ServiceRecord objects without even knowing if they are instance of
Local- or RemoteServiceRecord.

> 
> > > The native interface should only be a wrapper. Let's talk about the
> > > stuff and put some of it back to the Bluetooth library where it should
> > > belong.
> > 
> > I would say that 90% of the native interface is today a wrapper. Only
> > the service search uses home-made-functions derived from the BlueZ code.
> 
> As said already, lets fix this in the Bluetooth library itself. I know
> that SDP itself is a horrible mess of object oriented stuff, but I think
> we will find a solution for it.

Thanks!

Regards, 

Julien
> 
> Regards
> 
> Marcel
> 
> 
> 
> 
> -------------------------------------------------------
> This SF.Net email is sponsored by: Oracle 10g
> Get certified on the hottest thing ever to hit the market... Oracle 10g. 
> Take an Oracle 10g class now, and we'll give you the exam FREE.
> http://ads.osdn.com/?ad_id=3149&alloc_id=8166&op=click
> _______________________________________________
> Bluez-devel mailing list
> Bluez-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bluez-devel

Re: [Bluez-devel] Announce : BlueZ-based implemantation of JSR82

[Stephen Crane]

Yeah, having built a JSR82 solution with callbacks to Java from the
native layer for SDP, I can whole-heartedly recommend passing the
bytearray returned from the search back to Java and parsing it there.

I'd been thinking of splitting the SDP code along these lines: one base
layer which encapsulates the protocol and some user-space helper
functions which (de-)construct the byte-arrays passed to this base
layer. What do you think Marcel?

Another tip: only pass primitive types across the native interface. For
example, return an integer status and on the basis of that throw an
exception rather than constructing the exception object in native code. 

Good luck!
Steve

On Thu, 2004-05-27 at 11:21, Julien Campana wrote:
> Am Di, den 25.05.2004 schrieb Marcel Holtmann um 17:07:
> > Hi Julien,
> 
> Hi Marcel,
> 
> > 
> > > There are main reason why I rewrote some BlueZ functions is that:
> > > - Functions like "sdp_service_search_attr_req" return a list of
> > > sdp_record_t. If I had to parse these sdp_record_t  in order to
> > > construct the requested Java Objects, this would have been an amazing
> > > amount of switch or if statement. The best solution was therefore to
> > > directly send the bytes to the java implementation.
> > 
> > put this problem up in a seperate thread on the mailing list and tell
> > how the Java Objects have to look like. We should find a better solution
> > for that.
> 
> I will post this today or tomorrow. Furthermore, I will provide the
> HOW-TO help file next week (sorry for the delay, but I currently have a
> lot of work to do!). 
> 
> 
> > > > What I also don't wanna use is somekind of "de.avetana.bluetooth" vendor
> > > > extensions. If something is not possible in pure Java JSR-82, sorry not
> > > > my bad ;)
> > > 
> > > JSR-82 provides just the minimal amount of classes. It lets the
> > > programmer use "background classes" but this is transparent for the
> > > end-user (I will give some example of this transparency in the future
> > > how-to). These de.avetana.bluetooth.* classes are really needed to fully
> > > implement all javax.bluetooth.* classes.
> > 
> > You must explain this to me in detail, because I don't understand why.
> > Actually I think we should avoid this.
> 
> In order to explain this, I will take an example:
> JSR-82 provides an interface called ServiceRecord. The role of the class
> could be compared with the role of the sdp_record_t of BlueZ: storing
> attributes and related DataElements. 
> But no implementation of ServiceRecord is provided, it is just an
> interface. 
> Moreover, a look at the description of some JSR82 methods like
> LocalDevice.getRecord() shows that two kinds of ServiceRecord are
> needed: a "local" ServiceRecord and a "remote" ServiceRecord. This two
> ServiceRecord must differ (for example, the "local" Service Record does
> not implement some methods like getConnectionURL()). 
> That's why I had to provide two different implementation of
> ServiceRecord (LocalServiceRecord and RemoteServiceRecord). 
> But if you use the javax.bluetooth.* api, you will mostly manipulate
> ServiceRecord objects without even knowing if they are instance of
> Local- or RemoteServiceRecord.
> 
> > 
> > > > The native interface should only be a wrapper. Let's talk about the
> > > > stuff and put some of it back to the Bluetooth library where it should
> > > > belong.
> > > 
> > > I would say that 90% of the native interface is today a wrapper. Only
> > > the service search uses home-made-functions derived from the BlueZ code.
> > 
> > As said already, lets fix this in the Bluetooth library itself. I know
> > that SDP itself is a horrible mess of object oriented stuff, but I think
> > we will find a solution for it.
> 
> Thanks!
> 
> Regards, 
> 
> Julien
> > 
> > Regards
> > 
> > Marcel
> > 
> > 
> > 
> > 
> > -------------------------------------------------------
> > This SF.Net email is sponsored by: Oracle 10g
> > Get certified on the hottest thing ever to hit the market... Oracle 10g. 
> > Take an Oracle 10g class now, and we'll give you the exam FREE.
> > http://ads.osdn.com/?ad_id=3149&alloc_id=8166&op=click
> > _______________________________________________
> > Bluez-devel mailing list
> > Bluez-devel@lists.sourceforge.net
> > https://lists.sourceforge.net/lists/listinfo/bluez-devel
> 
> 
> 
> -------------------------------------------------------
> This SF.Net email is sponsored by: Oracle 10g
> Get certified on the hottest thing ever to hit the market... Oracle 10g. 
> Take an Oracle 10g class now, and we'll give you the exam FREE.
> http://ads.osdn.com/?ad_id=3149&alloc_id=8166&op=click
> _______________________________________________
> Bluez-devel mailing list
> Bluez-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bluez-devel
-- 
Stephen Crane, Rococo Software Ltd. http://www.rococosoft.com
steve.crane@rococosoft.com +353-1-6601315 (ext 209)

Re: [Bluez-devel] Announce : BlueZ-based implemantation of JSR82

[Marcel Holtmann]

Hi Stephen,

> Yeah, having built a JSR82 solution with callbacks to Java from the
> native layer for SDP, I can whole-heartedly recommend passing the
> bytearray returned from the search back to Java and parsing it there.
> 
> I'd been thinking of splitting the SDP code along these lines: one base
> layer which encapsulates the protocol and some user-space helper
> functions which (de-)construct the byte-arrays passed to this base
> layer. What do you think Marcel?

I think this is a nice idea, because this makes it also very easy to
store the SDP record on a filesystem for caching or anything else. I
have done something similar in the SDP code for libs2.

Lets talk about the API and then start coding this extension.

Regards

Marcel




-------------------------------------------------------
This SF.Net email is sponsored by: Oracle 10g
Get certified on the hottest thing ever to hit the market... Oracle 10g. 
Take an Oracle 10g class now, and we'll give you the exam FREE.
http://ads.osdn.com/?ad_id=3149&alloc_id=8166&op=click
_______________________________________________
Bluez-devel mailing list
Bluez-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bluez-devel

Re: [Bluez-devel] Announce : BlueZ-based implemantation of JSR82

[Marcel Holtmann]

Hi Julien,

> > > > What I also don't wanna use is somekind of "de.avetana.bluetooth" vendor
> > > > extensions. If something is not possible in pure Java JSR-82, sorry not
> > > > my bad ;)
> > > 
> > > JSR-82 provides just the minimal amount of classes. It lets the
> > > programmer use "background classes" but this is transparent for the
> > > end-user (I will give some example of this transparency in the future
> > > how-to). These de.avetana.bluetooth.* classes are really needed to fully
> > > implement all javax.bluetooth.* classes.
> > 
> > You must explain this to me in detail, because I don't understand why.
> > Actually I think we should avoid this.
> 
> In order to explain this, I will take an example:
> JSR-82 provides an interface called ServiceRecord. The role of the class
> could be compared with the role of the sdp_record_t of BlueZ: storing
> attributes and related DataElements. 
> But no implementation of ServiceRecord is provided, it is just an
> interface. 
> Moreover, a look at the description of some JSR82 methods like
> LocalDevice.getRecord() shows that two kinds of ServiceRecord are
> needed: a "local" ServiceRecord and a "remote" ServiceRecord. This two
> ServiceRecord must differ (for example, the "local" Service Record does
> not implement some methods like getConnectionURL()). 
> That's why I had to provide two different implementation of
> ServiceRecord (LocalServiceRecord and RemoteServiceRecord). 
> But if you use the javax.bluetooth.* api, you will mostly manipulate
> ServiceRecord objects without even knowing if they are instance of
> Local- or RemoteServiceRecord.

I remember the Java interface stuff and I never liked it. However if
this is what the specifications says, we have to do it this way. I will
offer the org.bluez.* namespace to be mostly clear with it, but we
should avoid it wherever possible.

Regards

Marcel




-------------------------------------------------------
This SF.Net email is sponsored by: Oracle 10g
Get certified on the hottest thing ever to hit the market... Oracle 10g. 
Take an Oracle 10g class now, and we'll give you the exam FREE.
http://ads.osdn.com/?ad_id=3149&alloc_id=8166&op=click
_______________________________________________
Bluez-devel mailing list
Bluez-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bluez-devel