Since syncing turned out to be less satisfactory than I thought, I started to add the missing TCP/IP transport to Nitro. Taking the OBEX layer out of Nitro was a logical consequence, with Neo as the result. The TinyTP/IrCOMM part of Nitro has been stable for quite a while now, warranting a 1.0 version number. Taking OBEX out of Nitro also make bug tracking easier.
Neo contains the previously released IrOBEX transport and a new TCPOBEX transport. The TCP transport is far from perfect (no status dialogs, no receiving), but it allows you to send vCard, iCalendar and other data to a desktop computer. Too bad that the available OBEX solutions for desktop computers are a bit unfinished... But OpenOBEX is good enough for that task.
Later, Neo might also contain an RFOBEX transport, if and when there is Bluetooth support on the Newton. We'll see...
After having recently upgraded to MacOS X 10.2 (never touch a running system! ... but the upgrade went without problems), I was finally able to try out Escale, NewtSync and iSync.
Turns out that syncing is still not where it should be. Here are some observations done after experimenting a bit. I could have spent more time on troubleshooting, but at the moment, I don't have that much time.
Escale (and the associated programs and libraries) looks like it will solve the problem of connecting natively (i.e. AppleTalk) to a MacOS X machine, and in addition to that, it contains a Rendezvous client for the Newton. Also, it contains libraries to understand the data stream coming from the Newton, most importantly, the dock application. In the end, it should be possible to write MacOS X applications that can talk to the Newton without any help from Classic, as well as applications on other platforms. Unfortunately, I couldn't get Escale to work (version 1.0.1), showing the same symptoms of inactivity as others reported on Newtontalk. For this reason, I was not able to check how well for example the Address Book synchronization would perform.
NewtSync on the other hand requires a client on the Newton to perform syncing. It has the definitive advantage of being extensible via AppleScript plugins to perform application specific syncing. The desktop client does not try to understand the Newton data format, instead, it lets the Newton client execute NewtonScript fragments to send data. The concept is quite nice, it could be used to sync almost any kind of data. But while the overall framework seems to be working, the actual syncing plugins need some work.
iSync however is a medium-sized disappointment. It would have been great to have a true SyncML client and server on the MacOS X side, instead, it is a proprietary solution (at least the client side that talks to the .Mac backend) and requires specific conduits to let a peer device sync as a client.
I think the best syncing solution would be SyncML-based, finding peer devices via Rendezvous and allowing any kind of data to be synchronized...