Crazy Idea No. 1
The existing IrDA tool on OS 2.1 creates a TSerialEndpoint when an application requests an IrDA connection. As we know, there is a little more massaging necessary so that the data that is sent over this endpoint conforms to TinyTP and IrCOMM. The same goes for receiving. In addition to that, data has to be sent in packets.
After the failed attempt to make the IrCOMM implementation look like a TSerialChip, the next crazy idea is to make it look like a TSerialEndpoint. This is several layers higher in the Newton’s comm stack and contains code that is called from the NewtonScript task (making it hopefully a bit less sensitive). The pitfall here is that the TinyTP layer must be able to receive a packet while sending and vice versa. Speaking in Endpoint terms, a Snd/nSnd must be possible right after a Rcv/nRcv, and a Rcv/nRcv might be needed before a Snd/nSnd without returning to the NewtonScript task. A workaround for this might be asynchronous send and receive operations.
An endpoint on the Newton is an implementation of the TEndpoint protocol class. Creating such an implementation involves providing a class declaration and definition which will get processed by the ProtocolGen tool, resulting in assembler glue code. The packager tool then prepares the implementation so that it will be registered automatically when the containing package is loaded onto the Newton. A registered protocol implementation can be instantiated using NewByName. Protocols can also be unregistered. This provides a nice way to extend or configure the system.
The problem in the current situation is however that the existing TSerialEndpoint code is to be reused since I do not intend to reimplement the rest of its functionality. But subclassing from protocol implementation classes is not possible so we have to chose a different approach here. First, we simply define the class TSerialEndpoint as it is currently implemented in the OS. When this declaration is passed to ProtocolGen, the resulting glue code references the existing TSerialEndpoint code (of course this requires setting up a jump table similar to CardGlue.a). Second, we override the necessary send and receive functions with our code. And third, we deregister the existing TSerialEndpoint protocol and register our own.
The first and third step already work and the new code gets called. The challenge is now to weave the IrCOMM implementation into this…