[Nxtcommand-developers] icommand.nxtcomm.bluez

[Peter J. <ptg...@ch...>]

Hi all,

I have been working lately on a java jni binding to BlueZ, the Linux
bluetooth stack.
Reason for this experiment, has been my experience with RXTX: when I run
into an error
situation its hard to get out of that situation and setup a new connection.

The jni binding has been tested with some sample Java programs running
the DIRECT commands 0x00 until including 0x04. It's remarkably stable.

You may start a Java program, notice your brick is not turned on, correct
the situation,
and as long as there is no timeout, your program starts after making a
connection. This
once happened accidentally, and has been tested more times for the fun of it
:-) I also
didn't have any trouble so far setting up a new connection after abortion
willingly or not
of a program. Ok, so far the selling the story.

Proposal:

I like to setup an area in subversion icommand-sandbox at the same level as
icommand-projects. icommand-sandbox is a playing ground for things that may
be integrated
in a future release. icommand-projects is for development, working on a new
release.

There will be 2 projects in the sandbox:
icommand-bluez (eclipse, java)
==============================
- java sources in package icommand.nxtcomm.bluez
   - class icommand.nxtcomm.bluez.NXTCOMM
   this is an alternative to icommand.nxtcomm.NXTCOMM
   so an end user, switching from RXTX to BlueZ (and back) only has to
change
   1 import statement in his code.

   There is 1 issue however. The NXTCOMM.open() is run from a static
initalizer block
   in the NXTCommand class. This makes it "impossible" to not use RXTX. My
proposal is
   to remove the static initalizer block, and make NXTCOMM.open() part of
the api.
   This means end users have to explicitly use NXTCOMM.open(). They already
have to use
   NXTCOMM.close(), introducing NXTCOMM.open() will only lead to a more
logically
   program structure (my personal opinion). Note: for the time being ALL
changes
   will only be happening in icommand-sandbox, also this api change.

icommand-bluez-native (eclipse CDT, c)
======================================
How about the name of the native library?
Proposal: libicmdbluez.so

If some C programmer will have a look at my C code, that I would really
appreciate.
Memory leaks, programming standards, ...
I have never done some serious C/C++ programming (before)
Brian, maybe someone of the lejos project can have a look?

Please let me know what you think about it. Shall I commit things to
icommand-sandbox,
when I am ready, then you all can have a look. I do not know if
icommand-sandbox and
icommand-projects will have separate revision numbers. There is 1 way to
find out.
Is this an issue ? (What's the alternative)

===

Now some other topic. For some time I want to setup a project making an
explorer like
NXT robot communicating with its base. That's how I run into ICommand and
got involved.
I like to setup a website to document the project and distribute the
software (Open Source).
The only common denominator (?) with icommand will be this java bluez
interface.
(I hope my english is correct).

I like to make the java bluez interface a part of lejos, but also want to
distribute it
as part of a software product from my website. I do not hope that
contributing the code
to icommand, implies loosing my rights to do so. Any comments ? What if my C
code is
significantly improved by some other Icommand developer? I am always willing
to give
credit to who it belongs. Now I know, why I never did have any aspirations
to become a layer.

I want to be honest, so telling this beforehand, seems the rigth thing to
do.

Peter Joosten.