FeedDemon 2.0 released

FeedDemon, the feed reader by Nick Bradbury, has been released in version 2.0. I have been using FeedDemon for my feed reading since its inception and I can totally vouch for it. A cheap, state-of-the-art feed reader with a built-in podcasting client. So it you’re looking to try something new, or just need a killer feed reader I would definately recommend that you check it out.

Does personal notes.ini settings roam?

According to a technote on www.lotus.com/support (“What Notes.ini values are stored and replicated in the Personal Address Book for a Roaming User?”) not all settings roam – I paid special mention to the fact that personal notes.ini settings, that is those that start with $-sign, doesn’t.

I called Lotus Support to verify that this is in fact correct since it could be considered a real issue since many applications use these personal notes.ini settings as part of the application. Not having these settings roam could really impact application perception by users. Here is the response I got from Lotus Support:

"PMR xxxxx,xxx,xxx is about the notes.ini parameter question an[d] the answer is no, but there is an enhancement request for this. Unfortunately this will not be fixed in R6. Would you like me to add your name to the list of customers who would like this to be fixed in R7?"

So I’m afraid the technote is correct. A SPR (Software Problem Report) for this was opened against R6 (SPR# DPAT4WSLVK) but it was decided that it wouldn’t be considered for the R6 codestream. I opened a SPR for the same issue against the R7 codestream. For those who want to add their voice to the SPR number is DPAT4WSLVK.

Managing external Java dependencies in Domino Designer

Please note: Lotus Notes/Domino will ignore the CLASSPATH variable set on the local machine. Likewise Notes/Domino doesn’t use Manifest files in jar-files.


One of the major advantages of developing in Java is the abundance of high quality open source libraries available to help you dramastically cut development time. Apache Jakarta and OpenSymphony are just two examples of sites that hosts high quality components you can leverage in your day-to-day developments (make sure to look into Jakarta Commons). The libraries are most often distributed in the form of one or multiple JAR files that you need link to when developing and compiling your code.

If you are unfamiliar with JAR files they are bascially ZIP files with a special directory structure. They are used to package compiled classes and let you handle one file instead of a whole directory tree. Much easier. For more information on JAR files refer to the page Packaging Programs in JAR Files at java.sun.com.

With external dependencies come complexity and issues as to where to place the JAR files so Domino Designer, the Notes client and the Domino server can find the code at design and runtime. When having external dependencies you basically have four options:

  • Include the classes in the agent/web service you are writing.
  • Put the classes in a Java script library and include the script library.
  • Use the JavaUserClasses notes.ini setting.
  • Put the classes in the jvm/lib/ext folder.

Below I’ll explain a little about each approach.

Include the classes in the agent/web service you are writing

This means using the “Edit Project” button in the Domino Designer Java IDE to include JAR files from the local file system in the agent/web service itself. This approach is valid and very easy to use but can mean dublicating the classes across multiple agents/web services in the same database. It is perfect for not having any dependencies outside the database.

Put the classes in a Java script library and include the script library

This means importing the JAR file(s) into a Java script library and then including the script library from agents/web services. This approach is for most cases the preferred way of using JAR files with Domino Designer since you avoid dublicating the code across design elements while avoiding dependencies outside the database. It also means that the code is easily shared among developers working on different agents concurrently.

Use the JavaUserClasses notes.ini setting

The JavaUserClasses notes.ini setting is the equivalent of the CLASSPATH setting used when developing in Java outside Notes. The setting makes the classes universally available so you can use them just like the classes from the java.*-packages lotus.domino.*-package. The setting is restricted in length (due to the limits imposed on notes.ini settings) and isn’t sharable across clients.

Put the classes in the jvm/lib/ext folder

Putting external JAR files in the jvm/lib/ext folder under your binary Notes directory affords you the same universal availability of the classes as the JavaUserClasses setting but without having to manually edit the notes.ini file. This possibility was introduced with Notes 6. Putting the classes in the jvm/lib/ext folder has some additional advantages when it comes to security but that’s for another post.

The table below shows the applicability of the different approaches.

td.center {
text-align: center;
}

Designer Notes Domino Replication Sharable Agent Web service Servlet
Include in agent + + + + – + – –
Include in web service + + + + – – + –
Script library + + + + + + + –
JavaUserClasses + + + – + + + +
jvm/lib/ext + + + – + + + +

As the table shows it is important to note that the JavaUserClasses and jvm/lib/ext approach are specific to the local machine that is it doesn’t replicate. This means that all installations (clients and servers) must maintain the setting manually. This can really be a hassle and doesn’t lend itself for use in applications deployed to end users. The approaches are very usable for servers though.

The table also shows that classes imported into a specific agent are not sharable that is you have to import the JAR file in every agent that uses the classes thus you have to remember updating the JAR file in every agent if upgradering to a new version of the JAR file. It can be a strength though if different versions are required. I recommend avoiding this approach whenever possible. Use script libraries instead.

Finally only the JavaUserClasses and jvm/lib/ext approaches can be used to load classes for servlets running under the Domino servlet manager.

Conclusion

In conclusion you should pay attention to what you are trying to accomplish when choosing the location for the JAR files you depend on. Each approach has its strengths and weeknesses.

For most cases the preferred way is using Java script libraries.

Improving Domino 7 and DB2 Performance

In this post on LDD John D Curtis links to a new piece of Domino 7 documentation titled “Improving Domino 7 and DB2 Performance”.

“Improving IBM® Lotus® Domino® and DB2® Performance contains information to help you optimize the performance of your DB2 server running in a Domino and DB2 configuration. . The information in this document is intended for configurations that utilize medium size servers because the parameters are tuned for medium size server systems. Other hardware configurations may require additional adjustments.”

The documentation database can be found on LDD in the Technical Library (scroll down to the bottom).

Domingo – a fresh start for the Notes/Domino Java developer community?

Domingo is an open source project hosted on Sourceforge that builds upon the standard Lotus Notes/Domino Java API. The Domingo website describes the project as follows:

Domingo is a simple, consistent, object-oriented easy-to-use interface to the Lotus Notes/Domino Java-API.

The project promises easier coding and no more manual recycling of objects.

It is still early in the lifecycle of the project so there is no real documentation up yet except for a small example. The Javadoc is available through and the source code can be viewed on Sourceforge.

I haven’t really looked into the project in great depths yet, but it is nice to see someone investing the time to build a more modern and up-to-date API for Java. It looks like the framework wraps the entire Notes/Domino Java API though it isn’t a drop-in replacement which is too bad since I think it will be a major barrier for adoption.

It’s going to be fun and follow this project.

Business blogging – an interview with Scott Anderson of HP

At the Blogging BOF at Lotusphere 2005 there was some discussion of blogging as a tool in business. Below is a link to an interview with Scott Anderson, Hewlett Packard’s Director of Enterprise Brand Communication, about blogging at HP:

“The blogosphere is changing how customers gather and consume information about the marketplace. Scott Anderson, Hewlett Packard’s Director of Enterprise Brand Communications took a huge step in bringing his company in line with the principles of open dialogue with its customers through the blogosphere. In this program, Scott describes the experience and the challenges of evolving corporate communication beyond the static web and into the live web.”

Business Blogging, Doing it Right

Show ‘n Tell Thursday: Validating XML when parsing with NotesSAXParser (23 Mar 2006)

When using and parsing XML for any purpose other than purely educational you really want to be using a DTD (Document Type Definition) to make sure the document is “valid” in the eyes of the application. This is possible both when using the DOM and the SAX parser, though there are differences as to when you might discover a violation of the DTD.

Using DOM a violation will be discovered before you actually start walking the DOM tree since the entire document is parsed and validated before control is given back to you as the programmer. Using SAX a violation is not reported until encountered which means that you might have parsed and processed most of the XML document so beware… When using SAX with a DTD you really shouldn’t consider any data from the XML as being valid until the SAX_EndDocument event has been raised (in the case of LotusScript).

To use a DTD with the SAX parser you really only need to be aware of the fact that the path to the DTD should be specified using the file:// protocol as shown in the example XML document below (notice the DTD import in bold):

<?xml version="1.0" encoding="iso-8859-1" ?>
<!DOCTYPE names SYSTEM "file:///c:/names.dtd">
<names>
  <name>
    <first>Mikkel</first>
    <last>Heisterberg</last>
  </name>
</names>

In this simple example the DTD is very simple and simply states that:

  • there is an element called “names”
  • the “names”-element can have 0 to many children elements called “name”
  • the “name”-element must have two children called “first” and “last” in that order
  • the contents of the “first”-element is parsable character data (#PCDATA)
  • the contents of the “last”-element is parsable character data (#PCDATA)

A caveat that most forget to mention is that the name of the top-level element should be named in the DTD import (<!DOCTYPE names SYSTEM…).

<!ELEMENT names (name*)>
<!ELEMENT name (first,last)>
<!ELEMENT first (#PCDATA)>
<!ELEMENT last (#PCDATA)>

Left is only to tell the NotesSAXParser to validate the parsed XML document against the specified DTD using the InputValidationOption-property (see code in bold).

Sub Initialize
  Dim session As New NotesSession
  Dim stream_xml As NotesStream
  Dim parser As NotesSAXParser

  Set stream_xml = session.CreateStream()
  Call stream_xml.Open("c:names.xml")

  'create validating parser
  Set parser = session.CreateSAXParser(stream_xml)
  parser.InputValidationOption = VALIDATE_ALWAYS

  'declare events
  On Event SAX_StartElement From parser Call SAXStartElement

  'start parsing
  On Error Goto catch
  Call parser.Parse()
  Exit Sub
catch:
  Msgbox parser.Log
  Resume finally
finally:

End Sub

Public Sub SAXStartElement(Source As NotesSAXParser, Byval ElementName As String, Attributes As NotesSAXAttributeList)
   Print "Encountered start of element: " + ElementName
End Sub

The above code can be copied into an agent in Domino Designer if you want to play around with it. To play around with it change the XML (e.g. by adding multiple “name”-elements and having the last one be invalid) to see how the violation isn’t reported until encoutered. Both the XML and the DTD goes in the root of the C-drive as the code is written.

Happy parsing…

Is the lack of Java skills in the Notes/Domino developer community the Achilles’ heel of IBM?

For years IBM has been preaching Java as the next language for development across the IBM suite of products. Still even with the immense focus very few Notes/Domino developers has seemed to lash on to the language. With the introduction of the Hannover client built on top of the Eclipse based Workplace client this will become a real issue in my eyes.

I think that the fenced-in comforts of the Notes/Domino platform have become a sedative for the Notes /Domino developer at large. Too long has the developer community been allowed to seek inwards and focus solely on the proprietary world of LotusScript, @Formula and simple actions to solve the issues at hand. I acknowledge that the @Formula language and simple actions definitely has their place in the Notes product and that these languages really shouldn’t be part of this discussion. My grievances are with the lack of new language adoption and if you live in the IBM World this new language is Java.

(As an aside it now appears JavaScript should also be considered an IBM World language with its introduction as a core language in the Workplace suite of products.)

I guess very few Notes/Domino developers who doesn’t program in Java (regularly or at all) wake up in the mornings and think they are missing out on something and that the consequences of missing out are going to be that big. I’m afraid they really are missing out and that it is going to be a big thing. The problem is however, from the standpoint of IBM, that the developers are not the only ones who are really going to suffer from this lack of Java adoption. IBM is going to suffer as well.

Instead of having a Notes/Domino developer community with a basic understanding of the Java language IBM is left with a community where probably as large portion cannot even write a simple “Hello World” application without the help of a book. In my eyes this is going to be significant since the move to the Hannover client framework will be real big thing for these people due to lack of Java knowledge.

I find this very sad since IBM had the possibility to prevent this from happening. No one could predict the future back in 1999/2000 and knew the direction that the Notes product was taking beyond the 5.x release which was a big thing. No one could predict that IBM would create the Eclipse framework and that most IBM client products would be based upon it.

But here we are, it’s now 2006 and I guess IBM has known for a few years that the Notes client would be built on top of Eclipse at some point in time. I therefore find it sad that IBM hasn’t been more active in driving the adoption of the Java language among Notes/Domino developers during the 6.x releases.

Because IBM is committed to the Notes/Domino product and due to the large population of custom applications out there LotusScript will probably be supported from now to the demise of the platform. Though supported it will be very difficult, if not impossible, to build the kinds of composite, networked applications that will be possible with Hannover using LotusScript. You’ll need Java for these kinds of applications. This brings us back to IBM since this fact will be a real Achilles’ heel when it comes to the adoption and getting the real benefit from the new Hannover client. The success of the Hannover client and the applications possible will rest on getting the customers to use and new features and begin to develop composite applications.

From my point of view I think there are a number of reasons for the lack of adoption. Probably the biggest culprit of the discussion is the perceived simple nature of LotusScript. Leaving Java on version 1.1.8 in the Notes/Domino products throughout the entire Notes 5.x codestream, the lack of proper UI support for Java and the complex and oftentimes impossible to comprehend and poorly documented security managers installed by the Notes/Domino JVM certainly didn’t help matters.

I make a point of saying the perceived simplicity of LotusScript since it isn’t in my mind an easier language to learn. I would even say that due to the lack of documentation and quality education material available for LotusScript, Java would probably be easier to learn than LotusScript for a new Notes/Developer starting of.

I am of the understanding that the difference between Java and LotusScript is just a matter of syntax. Nothing else. There is no need to completely understand the finer points of object oriented design to be proficient in Java. You can write as much procedural code in Java as you can in LotusScript. Of cause you can do considerably more stuff with LotusScript than Java in Notes/Domino but it need not be LotusScript or Java which is often the case in my experience. It has however become the reality that new developers learn LotusScript and not Java.

There is no need to begin to point fingers but I think it is sad that the state of Java development within the Notes/Domino developer community is what it is. The community at large needs to skill-up and get to grips with Java. Now is a good a time as any to get started – rather sooner than later. The reward will be apparent once Hannover is released.

Request for comments

For those of you who get this far – thank you for reading… 🙂 I would really appreciate your view on this. I’ll be happy to hear that I’m wrong but I am afraid that I am not.

How are roaming id-files encrypted?

The customer would like to move the user id-files into the personal name and address book to automatically have the id-files roam with the users. Technote 1102575 (“What information replicates to the roamed Notes Client from the roaming server?”) states the following:

1. User ID
- The user ID is stored (as a file attachment) in the Roaming User's Personal Address Book if the user's organization allows its replication, and if the Domino Administrator selected the option for replicating it. The user ID is doubly encrypted for added security before being attached.


- Because the user ID replicates, the roaming user will no longer need to copy it to different computers when modifying it (for example, by changing the password). However, until replication occurs, a change such as a new password may not take effect immediately. If this happens, try typing the previous user password.

I paid special notice to the sentence:

The user ID is doubly encrypted for added security before being attached.

This sentence raises the question of which keys are used for this encryption? It cannot be the id-file itself since it would render the id-file undecryptable. If cannot be the server id-file since it would make the id-file undecryptable if the user roams to another server. If it is some adhoc keys how does the user know how to decrypt the id-file at the next logon?

Does anyone know?

Looking at the names.nsf using NotesPeak reveals a profile document called “roaminguserid” with a file attachment ($FILE item). The item looks signed but there is distinguishable clear text.

It statement in the technote could of cause be erroneous (it wouldn’t be the first time)… Sounds like IBM Support is about to get a call.