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.