Thursday, 24 March 2011

Fixed LSXSD.LSS - Some more info...

With all my excitement having fixed LSXSD.LSS, I have posted the code without any further comments as to the changes I have implemented. I actually received an email asking me for the reason of having renamed the PortTypeBase class to PortTypeBase_NOT_A_CONSUMER, and this reminded me that there a few things that require an explanation:


LSXSD.LSS is normally included in the code using the %include directive. Apparently when including ans LSX, the compiler understands a compiler directive like this...

Public Class PortTypeBase
End Class
%End If

...which means the PortTypeClass is only included if the web service is a consumer. In my case the web service is a provider and hence I do not need that class.

Unfortunately the above compiler directive doesn't work when importing the LSXSD.LSS into a script library and then using the USE statement to include the script library. Hence I renamed the class to render it ineffective.

So to make it clear. If you replace the existing LSXSD.LSS on your Domino server or you copy this version of code with a new name to still use the %include directive, you need to rename the above class to its original name (removing the _NOT_A_CONSUMER part) and enclose the class with the %If WEB_SERVICE_CONSUMER_SCRIPTLIB...%end if directive.

If you want to use the code in  a script library, but you write a web service consumer rather then a provider, you also need to rename the class to its original name (of course without using the %if..%end if directive, as it would cause a compiler error).

There have been a few other changes as well...



The method notesStreamToBase64() previously defined as of type String is now returning a NotesStream. The reason being is that the original method used string concatenation to build the encoded return string, which causes the method to slow down exponentially to the length of the encoded stream; to a point where one needs to kill the server task.

The method now converts the input stream into a encoded output stream. One can then use the NotesStream.Readtext() method to receive the previously return encoded string.


Consequently the notesStreamToBase64Ext() method originally returning a string now returns a NotesStream.

I also removed the call of the IBM internal NotesStream.ReadEncoded() call as this method has a bug, which lets the method skip chunks of encoded data in the returned string. This happens randomly according to IBM, but my experience is, it happens to larger file sizes.

Another issue a found looking at the original method is that it uses On Error statements without the corresponding Resume statements.

The notesStreamToBase64Ext() method now simply calls notesStreamToBase64().


Though the code of this method is completely re-written, from a parameter and return value point of view nothing has changed.


Though the by IBM reported issue seems to be related to NotesStream.ReadEncoded() only, and NotesStream.WriteDecoded() seems to be uneffected, I have again removed the call of the IBM internal method and call only base64ToNotesStream().

NOTE: NotesStream.WriteDecoded() is obviously much much faster than even my improved decoding algorithm written in LotusScript. So you might want to switch back to it and only use the base64ToNotesStream() call if you experience problems with IBM's internal decoding method.


Similar to notesStreamToBase64() this method now returns a NotesStream. I implemented the same improvements.


No improvements here yet.

NOTE: If you have utilised the upload/download code provided in the Bookstore database available on, you need to amend the code to reflect the new return values where applicable. 

1 comment:

  1. This works, but I had to insert the creation/resetting of retStream in notesStreamToBase64 because otherwise I would get an 'Object variable not set' error.