Sametime blackboxes (update)

Just a short update on my Sametime blackboxes post from earlier today.

As noted by Julian Robichaux and Urs Meli in comments I had a typo in the previously posted code as I had managed to insert the wrong looping code twice… 🙁 The correct, correct looping should be:

public static void main(String[] args) {
   LinkedList l = new LinkedList();
   for (int i=0; i<10; i++) {
      l.addLast(new Simple(i));
   }
   while (l.size() > 0) {
      System.out.println("" + ((Simple)l.removeFirst()).getI());
   }
}

Sametime blackboxes

This week I have been writing an article on writing custom Sametime blackboxes for THE VIEW 2008 Technical Supplement and during my research I have stumbled across of number of interesting things. One of them is quite serious so I thought I ought to share.


You might not know this but when you hover your mouse over a contact in Sametime Connect 7.5 the data from the business card is actually retrieved using a servlet on the Sametime server. This servlet in turn uses a number of so-called blackboxes to fetch the actual information. You can write your own blackbox implementation using an API provided by IBM Lotus to fetch the business card data from another data source than the Sametime directory (whether that be Domino or LDAP).

First of all let me say that I like the idea of the blackbox API and that it makes total sense that I can extend the Sametime Connect business card system.

There is just two caveats I would like to point your attention to:

  1. The configuration file you edit is IBM Confidential
  2. The lifecycle methods are not called consistently

Configuration file

Blackbox configuration is done in a file called UserInfoConfig.xml in the Domino binary directory. On the top of this file there is a header saying that the file is IBM Confidential which to me is crazy since it’s for configuration and is publicly available.

Anyway this is just funny – the second part is worse.

Lifecycle methods

The interface you extend to write a blackbox has an init() method which is called once the blackbox pool is constructed and a terminate() method which is supposedly called upon blackbox termination. And here lies the problem – the terminate() method is only called for half the blackboxes. This is found out using a simple blackbox that writes to the Domino console once the different methods are called.

This effectively means that the whole lifecycle management cannot be used at all. The methods are there, I gather, to allow you to acquire long-lived resources in the init() method and assure their termination in the terminate() method. If the terminate() method isn’t called this can lead to resource leaks which isn’t very nice. What’s worse is that they can be very hard to diagnose.

I have found the problem in the blackbox pool code and it is a typical novice programmer mistake. Consider the following code:

import java.util.LinkedList;

public class RookieLooping {

   public static void main(String[] args) {
      LinkedList l = new LinkedList();
      for (int i=0; i<10; i++) {
         l.addLast(new Simple(i));
      }
      for (int i=0; i<l.size(); i++) {
         System.out.println("" + ((Simple)l.remove(i)).getI());
      }
   }

   public static final class Simple {
      private int i = 0;
      public Simple(int i) {
         this.i = i;
      }
      public int getI() {
         return i;
      }
   }
}

This code will result in the following output:

0
2
4
6
8

This isn’t what the programmer expected. He/she probably expected something like this:

0
1
2
3
4
5
6
7
8
9

If you look at the code you can probably see why. The for-loop used to remove elements from the LinkedList is the source of the problem. It only considers every second element of this list. A correct implementation could be (although there are numerous ways of doing it):

public static void main(String[] args) {
   LinkedList l = new LinkedList();
   for (int i=0; i<10; i++) {
      l.addLast(new Simple(i));
   }
   while (l.size() > 0) {
      System.out.println("" + ((Simple)l.removeFirst()).getI());
   }
}

I have reported this problem to IBM Lotus Support but for now, as of Sametime 7.5.1 CF1, you cannot rely on the terminate() method being called.

Just beware… (I have reported the issue to Lotus Support and is awaiting a SPR number).

Discovering Notes 8: More nice Notes 8 $fields


As posted on friday there is a nice-to-know field in Notes 8 you can use to enable/prevent automatic loading of images in HTML newsletters. This morning I saw two new fields that seems to have AppDev applicability:

  • $AttBytesTruncated: Holds the amount of (binary) data truncated from the document and hence the amount of data needed to be fetched in order for the document to be fully fetched. This is a number field.
  • $Abstract: Holds an abstract in plain text of the Body richtext field. This is a text field.

Both seems to be new (at least I haven’t seen them before) and set on by the Notes 8 client since I’m currently receiving my e-mail through a Domino 7.0.2 server (I know it’s horrible to hear) and they are not visible in the fields list until I replicate the database to my client.

Could be that it is simply because I truncate received e-mails but I don’t think so.

Discovering Notes 8: Automatic loading of images in HTML newsletters


In Notes 8 there is this nice new and improved display of HTML newsletters. An additional nice feature is that images are prevented from loading to combat SPAM bots that harvest e-mail addresses by using dynamic image URLs. See below for a screenshot of how a HTML newsletter looks before images are allowed.

It would however be nice if I could setup a list of e-mail addresses where image loading was enabled by default such as for my favorite HTML newsletters. Well it isn’t available out of the box with Notes 8 but you could easily write it yourself as an agent that processes incoming e-mail.

The agent only needs to set a text field called $DelayedImagesOK to the value “ok” (no quotes) for the e-mails where image loading should be enabled upfront.

Happy Friday!

Lotus Notes and Domino 8: What’s New in LotusScript and Formula Language

Rocky posted his slides from his “Lotus Notes and Domino 8:
What’s New in LotusScript and Formula Language”-session from the Advisor summit. Besides being an interesting read it had two slides that really caught my attention (slide 11 and slide 25).

When describing what’s new in the upcoming Notes 8.0.1 (1Q2008) he mentioned a welcome change to a dear old friend: @Now (see slide 11):

  • @Now([NoCache]) – when checking the time
    on a server forces a server transaction to fetch
    the time.
  • Without this keyword, @Now would cache the
    server time on the first call, and compute the
    current time by adding the cached time and
    elapsed time.
  • This causes problems if the system time on the
    client or server machine changes once the server
    time is cached.
  • Note that using [NoCache] adds the significant
    overhead of doing a server transaction on each
    call.

On slide 25 Rocky mentions two additional commands to the ReadViewEntries beside getting the output in JSON instead of DXL. The two new nice parameters are &EndView and &KeyType=<text/time/number>. &EndView returns entries from the end of the view and &KeyType allows you to specify the datatype of the key which allows you to use other key types than text.

Winds of change

I’m happy to announce that as of today I’m employed by IntraVision makers of the Ontime Calendar Suite for Lotus Notes, Microsoft Exchange and Novell Groupwise. It has been final for some time now but as of today it is public. After 8 years of being self-employed time had come for me to try out something new and I’m happy to join IntraVision. In my new job I’ll continue working with Notes/Domino and to service existing customers. I will also continue to be an active part of the Notes/Domino community.

Apart from the Ontime Calendar Suite some of you might recall the IntraVision from Lotusphere 2007 where they won a Lotus Award in the “Best Messaging and Collaboration Solution” category.

Feel the winds…