Just finished the latest version of Nitro. Quite some work has gone into the OBEX layer, but it is indeed a nice test of the lower layers of Nitro as well. There are still bugs in that lower layer that can cause nasty crashes or stalled communication, but I hope to get those ironed out eventually. One interesting discovery I made while debugging with Hammer is that the IAS implementation on the Newton is actually quite complete. IAS is used to advertise the IrDA services and parameters to peer devices, one example are the device name but also IrCOMM parameters. The part that made people believe the IrDA stack on the Newton is incomplete is only the NewtonScript interface. The rule to remember here: You don't know anything about a system unless you have really gone down to the metal!
The OBEX implementation in Nitro can be used also via other transports. It might be interesting to use TCP/IP or a serial connection. At least for Unix, there is Open OBEX that could be used on the peer side.
Clearly the next step after fixing the bugs is to implement the missing route scripts. Beaming text back and forth gets boring after some time! Sending iCalendar and vCard data is probably very easy, and some initial tests have shown that the routing stuff on the Newton is very well thought out. As soon as a route script implements the vCard or iCalendar conversion, it can be used over any transport, making it e.g. possible to send iCalendar entries via email.
The whole high level communications infrastructure on the Newton is fairly complex. It takes place mostly in the NewtonScript layer and is therefore built on cooperative multitasking: Instead of using threads and semaphores, callbacks are used. This requires much more careful design...
Anyway, the OBEX transport now works over IrDA. It does not handle error cases gracefully and contains no user feedback. But it is integrated in the Newton's I/O box mechanism so sending and receiving over IrOBEX just looks like any other transport (e.g. email). I can currently send text files to my cell phone or a desktop PC. This includes everything that has a textual representation on the Newton: Notes, Names, RSS feeds, ... Receiving files is not implemented yet but is hopefully not too difficult.
It will get interesting as soon as more routing formats are supported. iCalendar and vCard are one example. Routing formats are independent from the transport and can be used over any transport. The sending part of iCalendar and vCard is next on my todo list.
... that's the output I just got in my Inspector window. Communication via IrOBEX between my Newton and a Nokia 3650 works. Implemented at the moment are an OBEX server with the Put method and an OBEX client with Get and Put methods. OBEX is transport neutral, but as I wrote before, it is a nice test case for Nitro. It actually confirmed that I can set up a listening TinyTP endpoint (works for OBEX but probably not for IrCOMM which is of no big use in that case anyway) which I haven't tried before.
This is the plan: Wrap the OBEX client and server into a Transport for sending and receiving any file type via IrDA and TCP/IP. Implement a Routing layer for iCalendar and vCard datatypes (encoding and decoding), including a merge heuristic for incoming iCalendar and vCard data. Result: Making my Newton more usable in daily life, effectively saving its butt - I'm still resisting to buy a cheap Zaurus ;)
... are something nice. There was an interesting problem with Nitro when connecting to a Windows 2000 machine, causing an immediate crash. This was easy to reproduce and catch with Hammer. The problem was an IAP query frame sent to the Newton after successful connection. It seems that the lower levels of the Newton's IrDA stack can't handle this. The IAP frame was sent because the IrDA stack on Windows 2000 constantly sends out active connection requests which of course contain these frames. If the Newton also initiates a connection, then there is a chance that these frames get received at the wrong time in the protocol.
The solution is to defuse the stray IAP frame and turn it into a innocent IAP acknowledgement frame. I've still got to test this further but it doesn't seem to cause any damage. The result is uploaded as version 0.1.2. It would be nice if people who encountered crashes upon connection could try if it helps.
Version 0.1.2 also contains code to connect to other peer classes such as OBEX or IrLPT. This is based on the connection options passed to the NewtonScript endpoint. Nitro Test demonstrates this feature.
I've been busy working on OBEX (currently over TCP/IP, but it is transport independent). OBEX should be a valid test case for the TinyTP layer of Nitro. Nitro seems to be working best on Siemens phones and worst on Ericsson models. Testing this is pretty complicated since the means to signal an error condition (or even logging some data) from within a comm tool are quite limited. For now, the focus will be on catching potentially critical states in the protocol and not do something stupid.
Interestingly enough, Nitro seems to work my Nokia 3650 at least to some extent. It connects via a regular GSM data connection, but then the phone crashes after transferring some data. I'll have to try that with a more recent firmware for the Nokia.
I've also been able to finally try a USB/IrDA adapter under Mac OS X 10.1.5, and unfortunately, it doesn't work at all. I suspect that this is due to the adapter (an Actisys IR4000US), which isn't even supported under Linux. Other adapters might work - Apple is even selling them via their European web store.