Baps Delay

I was hitting a wall of bugs with my original version of the Baps app due to having to break requests in Bluetooth messages so I decided to re-write using streams (which is how data travels over regular network connections), which seemed like a really good idea but thanks to this 512 byte Nokia limitation/bug in JavaME it's going to take a bit longer to work around.

Bluetooth Access Point Service (Baps) Progress

Following on from this post I'm now adding new longer status updates as new posts.

The design of Baps has meant that the current implementation is mostly transparent and does not know about any of the underlying data being sent, contrasted with Hiisi which re-interpreted each http request. The benefit to my approach this is that there is less likely to be an error on my part in resending any type of data onwards, however the difficulty lies in that I still need to establish the destination addresses, ports and length from the data, but I don't have easy access to this information (technically I'm using raw sockets to send bytes rather than a http connection and APIs which could do this for me). This approach has led to delays such as working out content length resulting in "chunked" data and HTTP 1.0 data not being sent correctly (thankfully HTTP 1.0 is not too common and both have an easyish fix but I digress).

I've already started thinking about bluetooth drop out protection but this will be quite difficult to get right (the whole system needs to freeze immediately until the connection is re-established meaning existing requests and results are queued) or else the browser will not receive the results. For this reason it unlikely to be perfect or even in the first release.