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
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel
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
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel
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
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel
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
> > [email protected]
> > 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
> [email protected]
> https://lists.sourceforge.net/lists/listinfo/bluez-devel
--
Stephen Crane, Rococo Software Ltd. http://www.rococosoft.com
[email protected] +353-1-6601315 (ext 209)
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
> [email protected]
> https://lists.sourceforge.net/lists/listinfo/bluez-devel