So Notes 8.5.1 is out, and it's not bad as far as Notes clients go. My show-stopping bug is fixed, there's a slew of nifty user features, and, most importantly, they're taking concrete steps to improve the process of actually writing code for their platform.

As I'm sure you know if you've programmed in Notes, the LotusScript editor can be charitably described as "beta quality" and had, from all appearances, not been touched in any way since the addition of LotusScript in R4. Rather than list all of its horrible qualities, I'll try to leave it at this: the editor, from time to time, easts code. As far as I'm concerned, there's nothing worse that a code editor (or any editor, really) can do than destroy code, yet I can't tell you how many times Designer deleted an "End Sub" statement when trying to highlight an error somewhere in the body of the code, creating a nightmarish cascade of syntax errors and automatic code rearrangement. It's really bad.

So the addition of a proper editor for LotusScript (for agents and script libraries, at least) is HUGE; if I had had my choice about what made it into 8.5.0, I'd have picked this over XPages any day. Just the customization is a huge boost. For reference, here's the programming environment I use when I'm enjoying life:

And here's the old LotusScript editor:

Right. You can change it around a bit, picking your font (but not font style) and the text color (but not background color), but that's about it. This isn't even showing any of the behavioral problems like the handling of class definitions, the many bugs, or the paucity of useful features found in other editors like mass-indenting, code templates, and the like.

Now that it's a proper Eclipse editor, I can change it around more to my liking (we'll see if I stick with it exactly like this, but it shows the options):

Just as the previous screenshot doesn't convey the bugs, this one doesn't convey the overall feel of the editor. For lack of a better description, I'll say that it now feels like the text editor was designed with the expectation that a programmer might actually use it. I'm sure it'll have its own share of irritants (like having to manually delete the stub parameters when accepting a method auto-completion), but it's already made my job significantly less of a hassle.

From time to time, mostly for fun, I've wanted to figure out how to play arbitrary sound clips in the Notes client. From what I can tell, the "proper" way to do that is to use NotesUIWorkspace.PlayTune(), which, as with so many aspects of Notes, falls far short of what I want. I don't want to do any filesystem or network access (both because that's ugly and also because it should be cross-platform and not depend on being in the office), and so that just won't work.

A while ago, I came up with a method that kind of worked, using Java's "sun.audio.AudioPlayer" class and feeding it data pulled from an HTTP connection. However, this had a couple problems - the audio player returns control as soon as it starts, resulting in the code ending and closing the stream, so I had to either cache the data first or add in a loop to wait for it to finish. More problematically, though, it caused weird problems with the web server wherein the connections didn't properly close, bogging it down to unresponsiveness over time. So... scratch that idea.

Eventually, I came up with something that worked: access the sound files as NotesDocuments (I do it as file resources showing up in a $FormulaClass-modified view, but it should work as attachments to normal documents too), export the docs as DXL, pull out the Base64-encoded sound file data, translate that back, and feed it to the audio player.

I ran into some trouble instantiating some of the objects in a pure-LotusScript implementation, so the library is broken up into two parts: a LotusScript script library with a function that pulls an audio file from the storage DB by name and calls a Java method, and a Java library to do the dirty work of playing the audio. The LotusScript, cleaned slightly, is:

Uselsx "*javacon"
Use "Java Audio"
	
Sub PlayByName(fileName As String)
	Dim jsession As New JavaSession, session As New NotesSession
	Dim storagedb As New NotesDatabase(session.CurrentDatabase.Server, "storagedb.nsf")
		
	If Not storagedb.IsOpen Then Exit Sub
		
	Dim soundEffects As NotesView, effect As NotesDocument
	Set soundEffects = storagedb.GetView("Sound Effects")
	soundEffects.AutoUpdate = False
	Set effect = soundEffects.GetDocumentByKey(fileName, True)
		
	If Not (effect Is Nothing) Then
		Dim exporter As NotesDXLExporter, dxl As String, fileData As String
		Set exporter = session.CreateDXLExporter
		dxl = exporter.Export(effect)
		fileData = Strleftback(Strright(dxl, {<filedata>
}), {
</filedata>})
		Dim audioPlayer As JAVACLASS
		Set audioPlayer = jsession.GetClass("JAudioPlayer")
		Call audioPlayer.play(fileData)
	End If
End Sub

The Java code isn't much worse:

public class JAudioPlayer {
	public static String play(String base64data) {
		AudioStream audioStream;
		try {
			byte[] audioBuffer = new BASE64Decoder().decodeBuffer(base64data);
			ByteArrayInputStream inputStream = new ByteArrayInputStream(audioBuffer);
			
			audioStream = new AudioStream(inputStream);
			AudioPlayer.player.start(audioStream);
		} catch(Exception e) {
			String stackTrace = "";
			for(StackTraceElement element : e.getStackTrace()) {
				stackTrace += element.toString() + "\n";
			}
			return stackTrace;
		}
		return "Success";
	}
	
	public static void stop(AudioStream audioStream) {
		try {
			AudioPlayer.player.stop(audioStream);
		} catch(Exception e) { }
	}
}

Naturally, there's other stuff to worry about, like making the DB, setting up the way you want it stored (if you use normal documents with file attachments, the DXL-searching bit would have to be slightly different), etc., but this is the meat of it.

All in all, this has been working out pretty well. It's not perfect (exporting as DXL would have a lot of waiting time if the audio file is big or the network slow), but it works in Windows and OS X, hasn't caused any server troubles (always a plus), and, since the audio player returns control immediately, the UI doesn't lock up while the file is playing.