Build your own Domino hit counter (Page 2)

Search DominoPower's 11,422 Lotus-related article archive

Home
EasyPrint
News details

Articles-only

Twitter Feed

Build your own Domino hit counter (continued)

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:


' Byte-Serving Procedure Code

Sub OutputBinary(ImgHandle%,Byte&)

' ImgHandle% - file handle

' Byte& - byte value to be written to file with handle ImgHandle%



     Static LeftByte&

     Static Flag% 

     If Flag%=0 Then

          LeftByte&=Byte&

          Flag%=1

     Else

          If Byte&<0 Then Byte&=0

' check for special case of -1 (used to flush out byte buffer)

          If BigEndianFlag%=0 Then

' Intel word order

                  If Byte&>127 Then

                       OutByte%=Byte&*256+LeftByte&-65536

                  Else

                       OutByte%=Byte&*256+LeftByte&

                  End If

                  Flag%=0

          Else

'SPARC word order

                  If LeftByte&>127 Then

                       OutByte%=LeftByte&*256+Byte&-65536

                  Else

                       OutByte%=LeftByte&*256+Byte&

                  End If

          End If

          Flag%=0

          Put #ImgHandle%,,OutByte%

        End If

End Sub

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:


PRINT "[/counter/9996.gif]"

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.