Wrestling with buffer management between NewtonScript and Blunt ... getting hit by flow control problems ... wondering where all the bytes went ... crashing and crashing and crashing ...
... and then a quick, stupid test: Why not let Neo instantiate an RFCOMM endpoint instead of an IrDA endpoint? Change one line, add some instantiation options, initiate receiving on the Newton, open Bluetooth File Exchange on the Mac, hit send ... it works!
Now the first file to be ever transferred over Bluetooth from a Mac to a Newton sits in the Newton's inbox. Quite neat. I guess that's worth a nice Westmalle Dubbel.
... made it safely from the Mac OS X Bluetooth File Exchange application through various layers of protocol handling code in Blunt to show up in a text view on the Newton. The seven bytes are an OBEX connection request.
Now I've got to add code for sending data back, check the necessary flow control mechanism and the first third of the Bluetooth integration is done. It would already allow sending files to the Newton via Bluetooth. The second third is initiating connections instead of listening and the last third is cleaning up things (mostly SDP) and adding a setup application.
Who did this!? It's like talking in gzip! ... what I'm talking about is the Service Discovery Protocol (SDP), used to find the services running on top of a Bluetooth stack. It uses a very compact binary data representation which might be space efficient but very inconvenient to parse. Oh well.
On the brighter side of things, I've managed to restructure some of the higher level Blunt code without breaking too much. Now there is some degree of multiplexing possible. I also had the idea of using a permanently operating Bluetooth stack which could have multiple comm tools as clients. This could be really interesting to run multiple services on the Newton as well as sending data at the same time. I have to remember why that idea didn't work with IrDA, there must have been a catch.
Totally unrelated, but in case anybody missed it (that's not really possible, is it - there is this really practical RSS channel on the 40Hz SourceForgepage !): Courier 0.3 and Raissa 1.1 are out.
From a Newton to Mac OS X and a Nokia 3650, using Blunt. Not too bad. At the moment, the code looks a bit hacked together (well, that's what it is), and the usual "hack - refactor - hack" cycle has to start sometime. But for now, it's good enough. Next up is initiating connections.
At the moment, it's fill-in-the-blanks for Blunt. The Bluetooth specification is quite clear, I have two peer devices to test with, the comm tool integration is working so far - now all those functions, states and packet formats have to be implemented! I can already accept incoming connections at the HCI level, but there is much more to come, such as the service discovery protocol.
Bluetooth support will consist of two main pieces: The RFCOMM communications layer (realized as a comm tool) and the Bluetooth Setup application. The RFCOMM layer will handle HCI and L2CAP to provide a serial port over Bluetooth. The Bluetooth Setup application will handle the rest, including discovery and pairing. It can actually be implemented in NewtonScript, I'll have to see about that.
There is also the area of Bluetooth by-products. At the moment, I'm thinking mostly about location-based services. It would be quite simple to let the Newton scan its Bluetooth neighborhood upon wakeup to determine where it is at the moment. It is also easy to advertise its presence by simply being discoverable for some time. All this could be done at the NewtonScript level.
Unfortunately, the current architecture restricts usage of the serial port to one program at a time. As an example, a location-based service would have to share the port with the receiving transport and the sending transport (Neo). Unless I figure out something smart such as multiplexing at the Endpoint level...
Ok, if you want to check if a Bluetooth card you have might be supported by Blunt, check the Experiments page.
Also, please take a look at the 40hz.org main page. At the top of that page are some links to the new SourceForge support page, the RSS feed for new releases and the support mailing list. And the "Donate" button ;)