Adrian,
Thank you for you comments and the effort you have spent working with our
IrDA implementation.
1) There is a known bug in the stack where it can get frames out of sync
under certain timing conditions. There are also some places where frame
timing is not within IrDA specs. The IrDA stack is implemented as a library
so that we can update it as we find bugs. The update for IrCom does include
some other stack fixes.
Since the IrDA library can be a activated at any time for beam receive, it
had to have a miminal memory impact. So we made the standard configuration
run from the UI thread. This keeps the overhead down to a few K instead of
using half the available memory like the TCP stack. When we run IrComm, the
IrDA stack does run in a background thread. In my experience, timing
problems are usually more related to stack bugs than to
forground/background thread issues.
2) The Exchange Manager uses OBEX by default (in fact it does not support
anything else right now). It is recommened that most palm apps that have
data to share implement the exchange manager for sharing that data. This
will become a very powerful feature of the PalmOS. Applications that have
specific needs for other IrDA protocols can use the IrDA library to
communicate in many other ways.
3) Most of the devices beyond Palms, laptops and Printers, did not exist
when we developed the stack, so there was no way to validate against them.
IrDA is a growing standard and there are a lot of variations out there. We
did our best in the first release to work with everything we could find,
but we knew that a full validation against every device would take a long
time if it could be done at all. So we released the product with support
for Palm to Palm Ir and a best effort, but unsupported implementation for
connecting to other devices. We will continue to work on upgrading our
stack and supporting other devices as those implementations stablize.
4)I absolutely agree that OBEX is only part of the interoperability
solution. That is why we spent the time to implement vCard and vCalendar
formats for exchanging data from our built in apps. We did not need to do
this for palm to palm support. It was done so that we could communicate on
a content level with other devices. I have been actively encouraging other
IrDA members to support these standards so that there is real content level
interoperability. Our notepad supports standard ascii text (.txt) files as
well as multi-part MIME and quoted-printable text. OBEX was selected
because it allows us to communicate information about the content of the
data and not just a filename.
5) IrComm is now provided for those who need it to communicate to existing
applications. IrComm does use a LOT more overhead than the standard stack.
We have provided the other APIs to encourage developers to make full use of
the IrDA protocols.
--- Gavin
>Date: 30 Apr 1999 09:00:16 -0700
>From: Adrian Pfisterer <[EMAIL PROTECTED]>
>Subject: Re: transmitting data by IR
>1. Palm devices are marginally IrDA compliant. There are some timing
>requirements
>that are not followed strictly. Also, it is too simple for a developer to
>make
>the device break the IrDA protocols due to the fact that the IR code runs
in
>the same thread as the application and can't get the processor when it
needs
>it.
>(BTW...this is different from the network library which has its own
thread)
>2. Palm devices don't talk IrOBEX by "default". The built-in apps happen
to
>support
>IrOBEX. Both the Exchange Manager (IrOBEX) and the TTP/IrLMP API's are
>accessible to developers.
>3. It has been my experience that using IR with non-Palm devices is not
>easily done. Connecting (at the IrLMP layer) to various laptops via IR
>has been unreliable at best (granted, due in part to Microsoft's and the
>laptop manufacturer's dubious IR implementations); a race condition (bug)
>exists
>in the Palm III IR stack that makes my application incapable of connecting
to
>all but the most forgiving of passive devices; similar frustrations exist
>with WinCE devices, digital cameras, and cellular phones. There's a whole
>ecosystem out there beyond Palm's and printers and laptops. And the IR
>connectivity is not there. Hence my interest in Palm's extending their
>'official' support beyond other PalmOS devices.
>4. Installing IrOBEX on other devices does not solve the interoperability
>problem. It merely moves the problem further up the protocol stack to the
>application layer. With IrOBEX I can still receive data I can't do
anything
>with (similar to getting an AmiPro document via email and not being able
>to read it). This is not my idea of a seamless use model.
>5. For years IrDA has been trying to steer people away from IrCOMM. It
takes
>over the whole link and IrLMP, which is there to provide session
multiplexing,
>is
>useless when IrCOMM is active. Doesn't make much difference to a PalmOS
>device since it is 'single-tasking' but Palm supporting IrCOMM means
devices
>it
>is talking to must be dedicated to that session.
>Adrian Pfisterer.
>Hewlett-Packard.
