Wednesday, 23 March 2011


For those of you who require to use the Base64 upload/download features of the LSXSD.LSS and having trouble because of the by IBM reported issue...

...and cannot wait for the fix...

I have re-written the Base64 encoding and decoding methods and use it by importing the code into a script library. Instead of using the %Include statement, I use the Use statement. Hence instead of rolling out a custom LSX, I place the custom code in my databases.

Whilst the original Base64 coding algorithms in LSXSD.LSS are performing dead slow (anything beyond a few KB file size can actually keep the server busy for very prolonged periods (hours!) - see ...

... - the code provided in the link below manages MB sized files in seconds:

3.2MB encoding in approx. 20 seconds
3.2MB decoding in approx. 10 seconds

Whilst this performance is still considerably slower then the in Domino 8.5 introduced internal encoding/decoding methods of the NotesStream class (for the same file size about 1 second), the modified code works reliable!

The code can be found here...


  1. I am curious what you mean by a 3.2MB encoding. Do you mean that the result is 3.2MB, or the original file?

    I also have to say that while there is a great benefit to having everything in a LotusScript library, don't dismiss a custom LSX too quickly. When I encode a 3.2MB file to Base64 with our Midas Rich Text LSX, along with writing it out to disk and doing a few other things, it takes less than a second. Depending on what your lag requirements are, even 10 to 20 seconds can be a long wait.

  2. Hi Ben, the original file is 3.2MB, the encoded file is of course larger in size. In matter of fact, due to the fact that the data transfered is a stream of type string, the data size transfered is actually more than doubled (as a string is transfered as unicode, hence at least 2 bytes per character)

    As I stated: 10-20 seconds is long, but certainly a lot faster than 3+ hours (original LSXSD.LSS code).

    The internal ReadEncoded() method of the NotesStream class also works in a 1 second time frame, however, it has a bug for larger file sizes. Hence it is not usable at present. The fix will eventually come in 8.5.3, but that is not certain.

    In this respect the code I published is free and offers a quick fix to the current Domino versions. Of course anyone can go for a 3rd party solution to get best results, no question about that.

  3. Ben, in addition, every performance test obviously depends on the hardware you test on. My test are done on a HP Elitbook 2730p running Windows 7 Ultimate and Domino 8.5.2 64bit for Windows. I'm certain that on a real server better performance is reached.

  4. Absolutely right on both counts. Your fix is free, and a great solution. My only point was that you dismissed the idea of a custom LSX, and I wanted to suggest that it shouldn't be dismissed too quickly, whether or not anybody wants to roll their own (there are plenty of open source implementations of B64 encoding), or buy something.

    Fwiw (not much), I ran my test on an 8 year-old PC running Windows XP and Domino 8 32bit for Windows and didn't even pause AVG which is doing a full scan. Not that it speaks for the speed of Midas as much as the speed of C code versus LotusScript, which I think people sometimes don't fully comprehend.

  5. OK, misunderstood you in that. Of course you can use the code as LSX. I thought that would be obvious, so I just explained that you can import the code into a script library instead. Anyway, I believe now it is clear to everyone :-)

    And of course LS cannot compete with C. In matter of fact I was delighted to see that I managed to get the encoding/decoding alghorithm with LS as fast as they are now. I wasn't expecting this at all.

  6. hmm, lsx code has gone !poof!

    Please provide a link!

  7. Ooops. I restored the link

  8. The Link is dead again

  9. Sorry for that, but is down or pointing to this blog respectively. This is permanent.

    Please download from The contained soapgate_os_4.ntf template contains the LSS as a script library.