Showing posts for tag "notes"

Sync

Oct 25, 2011 9:52 PM

So there's a new round of talk lately about syncing and the trouble involved, thanks to some changes in Google Reader's behavior and the desire to find a new safe haven for RSS syncing. The best example is, unsurprisingly, from Brent Simmons:

Google Reader and Mac/iOS RSS readers that sync

However, the whole time I was reading this article, my brain kept yelling at me, louder and louder as time passed:

This is Lotus Notes! The system you're describing is Lotus Notes! It does syncing and deletion stubs and read marks! IT'S LOTUS NOTES!

This kind of thing would indeed be really easy in Notes/Domino, particularly if you were actually using the Notes client (though it wouldn't be much to look at). Subsets of data, managing deleted elements, timed refreshes from the source, storing each feed entry as its own entity, and offline access that can have its changed synced back to the master are all things that Notes has done since its conception - the only problem is that it's so ugly and arcane that mass-market appeal is nigh-impossible.

Nonetheless, it got me thinking about the viability of using Domino as a syncing server for this. You wouldn't be able to use NSF files in your RSS clients, which would make the job a bit tougher, but the new "XWork" licensing model would fit into this nicely. Scalability would be a serious concern, but the simple nature of the data would keep view updates quick, and it'd just be a bit of cleverness in the database layout to direct users to the correct place. Toss a couple clustered servers in there and you should have some good load balancing, too. The Domino Data Services API might be enough to handle data access from the client, but, if it's not, a couple simple agents would do it.

I'm sort of tempted to try hashing something out.

It's Still Lotus Notes

Sep 17, 2010 7:35 PM

Tags: notes

XPages are a huge divergence from classic Notes development. Aside from a few token UI controls such as View Panels and some support for Domino data on the back end, they may as well be completely unrelated to Notes.

Now, while IBM didn't take many strides to make the transition from old-style to new-style development easy, they DID make sure to keep the most important part of the Notes experience intact: horrifyingly frustrating bugs! Case in point:

All I wanted to do was delete the attribute value, but every time I did, the XML editor decided to eat a couple extra lines of code. The "select all" effect you see is from hitting ctrl-Z, which is supposed to only select the text that was un-deleted, but, since the editor has no idea what's going on, it throws up its hands and selects all kinds of crap.

Between this kind of thing and all the random crashes, it's comforting to know it's still the same level of Lotus quality we've come to expect.

Notes 8.5.1's new LotusScript Editor

Oct 15, 2009 11:22 PM

Tags: notes

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:

TextMate

And here's the old LotusScript editor:

Old 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):

Eclipse Editor

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.

Playing sound in the Lotus Notes client

Oct 15, 2009 10:47 PM

Tags: notes

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.

Lotus Notes

Feb 12, 2009 11:55 PM

Tags: notes

I generally do a lot of ranting about Lotus Notes, so I figure it's only fitting that I make a blog about it.