Re: [Nxtcommand-developers] icommand.nxtcomm.bluez

[Brian B. <bba...@mt...>]

Hi Peter,

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

You don't have to be timid about making changes to the iCommand code. If you 
have something that is working just throw it in subversion. Consider your 
own PC as the sandbox to play around with code, and then commit changes to 
subversion when they are working or somewhat working.

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

I had an email from someone who changed the code to use the Java comm API so 
he could run it on his handheld with Windows Mobile. That got me thinking 
that we should add another optional variable to the property file to choose 
which serial package you want to use. We could have RXTX, Java 
Communications API, Bluez, and even possibly the Lego Fantom driver. This 
would let us test and compare to see which works best.

So rather than a package for each, we could just make an interface called 
NXTComm with the relevant read and write methods, then have BluezNXTComm, 
RXTXNXTComm, etc... The code could default to the best/most common one but 
if the variable exists then use the appropriate object.

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

open() and close(0 sound good. It would also let the programmer control when 
they want that 5 second handshaking delay to occur.

A user named Rojit from the leJOS mailing list says he got more than one NXT 
brick working with iCommand but then I changed it to singleton static method 
calls to match leJOS (i.e. Motor.A.forward() instead of 
nxt.motorA.forward() ). Not many people have multiple NXT bricks but if it's 
possible to control more than one through Bluetooth we should implement it 
somehow. If we do use multiple instantiations, we could do away with open() 
and close() althogether. People seem to favor the commands that match leJOS 
though. I'm not really sure what to do.

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

You could ask Lawrie Griffiths if no one on this project can do it. He's 
pretty busy with leJOS NXT though.

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

iCommand is under the GNU GPL so anyone can take the open source code, 
modify it and redistribute it. I think the major limitation is that you 
aren't allowed to sell it or something like that, and it has to remain open 
source so everyone can see the code. I'm not an expert on GPL but that's 
what I got out of it.

- Brian