However, as usual, Domino is flexible enough to allow workarounds for these limitations. The minimum 16-bit output size can be fixed by writing a procedure to buffer output, as demonstrated below. Secondly, there is a neat way around the Print statement limitation, and one that enables a whole bunch of serious optimizations.

Here's a chunk of code that will enable byte-serving:

Here's how you would use that procedure:

• Set the global variable BigEndianFlag% to 1 if running on SPARC, RS6000, SGI processor;
• Call OutputBinary for every byte;
• After the last byte has been output, call OutputBinary with a byte value of -1 to flush the buffer

Rather than send the binary data (in this case the pixel bytes of a GIF image) directly to a browser as you would HTML, use the old-fashioned Open/Close/Put statements that LotusScript has inherited from Ye Olde Basic. Write the binary data to a file using the buffer procedure. Then send the browser the address of the file, enclosed in square brackets. This acts as a redirect, forcing the browser to immediately start loading the file, as if it had been directly byte-served from Domino.

For example:

Optimizations
I suggested that this approach to byte-serving opened up a new realm of optimizations. Given that the most complex part of such an agent will be the intensive graphics processing to build a GIF image in LotusScript, why go through that process if there's a GIF file lying on the server that's previously been constructed for the same number?

Thus, a cache of recently used images (and since there are only ten digits, that's a relatively small cache) can be built up. To keep things under control, some sort of regular purge is required--another Domino agent easily takes care of this on a weekly schedule.