One of the recurring problems in Blunt is that there are actually two different layers of communications, each with different semantics. As an example, connecting to Blunt itself is a bit different than connecting to a peer device. On the lower level, the CommTool is connecting to the serial chip, and that's it, whereas on the higher level, the whole Bluetooth connection setup process is done.
Semantically, the connection is mapped to the Bluetooth world, which means that whenever a problem occurs in connecting, the cleanup actions require a lot of asynchronous messages, e.g. tearing down the HCI or L2CAP links. This error handling is not implemented very well in Blunt. Right now, Blunt has problems cleaning up everything, but things work better when they are triggered from the NewtonScript side. One way to deal with this is to let the NewtonScript side always to the cleanup, but this requires that timeouts are used, or that the user is able to cancel things.
Since I took my Newton on vacation and checked it in with my bags on the return flight, it seems that Bluetooth is not working from time to time. Maybe my excellent soldering job broke? Anyway, this is a clear sign not to let your Newton travel alone in the cargo bay! I guess I'll have to open the poor thing to see if the module is still where it should be... and I have to improve the error handling in Blunt, rebooting whenever something goes wrong is certainly annoying. Once that is done, it's time to release Blunt as version 1.0.
I thought I write a bit about the T68i and using it with Blunt, it seems a quite likely combination. I have at least one report of a bug which causes a PPP connection to be terminated after some time, and I was able to reproduce it. The Newton PPP implemementation sends echo packets if the link has been idle for a while, and it seems that the T68i does not support this. This is however a bit strange since it should be a server issue, not a phone issue. But I cannot reproduce the behaviour with the same provider and a different phone...
The consequence is that whenever the PPP link is idle for a while, the connection is terminated and you have to dial in again. Quite annoying! On other PPP stacks (such as on Linux), you can turn of the sending of echo packets, but unfortunately not on the Newton.
That was a truly amazing conference! Lots of great people, beautiful location, interesting talks - the community is still going strong after so many years, and it was especially good to see that there were also users present, not just developers. I'm sure next year's conference will be as great as this one!