Month: April 2007

A bit disappointed with Sametime 7.5.1 screen capture annotations

As previously mentioned I upgraded to Sametime 7.5.1 yesterday to follow along but also because of the update to the screen capture utility which I use a lot. Although the new functionality is nice it falls short of actually replacing manually using SnagIt! that I otherwise use for screen capture. I know that SnagIt! does a lot more, but when I need to capture some part of my screen and send it off I almost always need to highlight or annotate it in some way before sending it off. That being said I like the ability to automatically send the screen capture to chat partner(s) from the annotation window.

I would think that the basic required annotation tools would be:

  • Ability to draw basic geometric shapes (circle, square, line) apart from freehand
  • Ability to use different colors based on color picker
  • Ability to add text
  • Ability to add arrows
  • Ability to adjust line thinkness

I guess that the above can be consider a feature request… 🙂

Upgraded to Sametime 7.5.1


I upgraded to Sametime Connect 7.5.1 this morning to test it out and to take advantage of the new features. I’m especially looking forward to screen capture annotations – the new tabbed chat interface will also be nice.

The upgrade process itself went smoothly, but unfortunately there was an issue which makes it a no-go for us for the time being. The sametime.ini file was replaced and since we have made customizations to that an out-of-the-box installation is a problem for us. Whether modifying the sametime.ini is supported at all I do not know but it doesn’t change the fact that sametime.ini was replaced… 🙁

Another issue is that the UI has been slightly modified. Apart from the general color scheme and that the “Primary Contacts” miniApp has been added per default at least one menu item has been moved. The one I’m looking at is the action for managing plug-ins which used to be at “File -> Manage Updates -> Configure…” but in Sametime 7.5.1 is at “Tools -> Plug-Ins -> Manage Plug-Ins…”.

This isn’t too bad – I actually prefer the new location. The problem is that my next/newest article for THE VIEW just went off to the press and the article contains numerous screen shots – some of the functionality for managing plug-ins. I smell an Sametime 7.5.1 errata coming up… 🙂

Saved by NOMAD

One of my colleagues Thinkpad crashed on Friday afternoon and was sent to the repair center on Monday morning. Due to this crash he didn’t have access to Notes e-mail or any of our databases during the weekend. Fortunately he installed a 4GB USB-stick with NOMAD (Notes, Designer, Administrator 7.0.2) some weeks ago so he has been able to continue working of any spare computer available. Only requirement – an USB port. Nice! Zero actual downtime work wise.

Only downside is the lack of VPN support to run off a USB key.

I’m just afraid he’s growing too fond of not having to lug his Thinkpad around… 😉

Preferred LotusScript comment style

As previously mentioned I’m looking into starting development of LotusScript.doc version 2 and for that I’m also rethinking how comments are written when writing LotusScript. In version 1 of LotusScript.doc I have only supported a LotusScript’ified version of the Javadoc syntax which meant that only the following comment syntax is considered valid:

'/**
' * This is my comment for the DoStuff sub-routine.
' */
Public Sub DoStuff()
   ...
End Sub

Comments of this kind can be placed inside or outside of code constructs (class, sub, function etc.) and will be picked up by LotusScript.doc accordingly. Apart from this you can write a description for a design element by using the lsdoc_description() sub-routine. This is the equivalent of the package.html from javadoc. Normally it would be used like this:

Private Sub lsdoc_description
%REM

%END REM
End Sub

For LotusScript.doc v. 2 I would like to make this more flexible and support multiple commenting schemes so I’m thinking:

  • “How do you comment your LotusScript?”
    • Do you comment using %REM sections?
    • Do you comment inside or outside the sub/function/class etc.?
    • How do you document the design element it self?

Also – one thing is how you do it now – another is how would like to document your code in the future.

I would really appreciate any input…

E-mail question: Notes/Domino Java API development for Sametime Connect

I received an e-mail from a reader of the blog asking some questions on developing Sametime plug-ins using the Notes/Domino Java API. Since the answers might be of benefit to others I’m also posting the reply here. Please note that my upcoming article in THE VIEW will go into a lot more detail on install handlers, native library loading in Sametime etc.

I really wanted to talk on this at ILUG 2007 since I think it’s an issue which will come to haunt a lot of developers, but unfortunately I was unable to get in contact with Paul Mooney so I wont be there… 🙁 

<Name>,

well you are really opening a big jar of issues and I'm afraid that it would be too time consuming for me to point out what you need to do in detail. The article you mention will show you exactly how to do what you need. I can however give you a pointer... :-)

If you get a java.lang.NoClassDefFoundError it sounds like the actual class from notes.jar (lotus.domino.Session) isn't on the runtime classpath of the plug-in. Look into adding it to the deployed plug-in. Do this on the Build tab of the MANIFEST.MF file in Eclipse (use the Binary Build section on the lower left).

Additionally if you haven't already be sure to read my post on plugging the necessary classes into Eclipse for Sametime development using the Notes/Domino Java API.

Please note that if you are using local sessions you need to modify the Sametime Connect client sametime.ini file to enable it to correctly load native libraries on Windows (DLL's). This is best and most easily done using a feature install handler which is a little advanced but it will be thoroughly explained the my upcoming article.

Hope this helps.

Version 2

I’m starting to think of features and improvements for LotusScript.doc version 2 and was thinking what you had to say… What issues/problems do you have? What kind of features are you lacking? Please let me know so I might include them.

Please send comments and suggestions by e-mail to lekkim [at] lsdoc.org or as comments to this post.

Thanks.

What’s the future of Java in Notes/Domino?

At Lotusphere 2007 there was a session on the future directions of Java in Lotus Notes and Domino called AD508 (AD508: Java 5 Upgrade for IBM Lotus Notes and Domino). Basically the session discussed the future of Java in Notes/Domino and how IBM is planning to ship Java 5 as part of Notes 8/Domino 8. Unfortunately I haven’t had the time I wanted yet to play around with version 8 yet so I cannot comment on whether Notes/Domino 8 already has Java 5 – the Reviewers Guide says that it has though.

For those not in the know Java 5 introduced a number of new core language features which are definitely worth the upgrade but the most beneficial for me is the enhanced for-loop and generics. There are a number of additional API changes that makes life much nicer from the programmers point of view. This is all well and good but Sun Java is currently in version 6 and have been for a while now and Java 7 is currently being planned and scoped out. Java 6 has a number of additional features that would be nice for Notes/Domino programmers such as JDBC 4, new APIs for web-services and improvements to the Java Platform Debug Architecture (JPDA). Only going to Java 5 in Notes/Domino 8 seems like a bad choice.

Why would IBM not want to go directly to Java 6? It could be that, as of today, IBM hasn’t shipped a Java 6 development kit yet and since IBM probably wants to include their own JDK it might be why. Another reason could be that IBM Lotus Expeditor doesn’t run on a standard JDK but on the IBM J9 VM which is a scaled down version of the JVM with a limited set of API classes. With not even a Java 6 JDK ready I would guess that a Java 6 version of J9 is a long way off. The fact that Lotus Expeditor is based on J9 causes its own set of problems for plug-ins in Sametime 7.5 (as previously mentioned) but that’s another story.

I fear that since Lotus Expeditor now is the base platform for IBM client products and since IBM probably wants to avoid shipping two JVMs with the product they will stick with J9 for some time. Given I don’t know the exact technical reasons for J9 and there are performance to think of as well (JVM reuse for client platform code and client side Java) I find that a real shame. It would be a really big loss.

Suddenly the supported Java version will be tied to the JVM running the client and we as developers and customers will be tied to using back-level APIs. For trivial agents etc. this is probably not going to matter anyway since the Java API hasn’t been updated since its inception. For new code it is going to be a real show-stopper. Most new code and components are created by combining existing (open-source) modules into new code and modules and with most open-source projects being at at least Java 5 by now it is going to cause problems. I know Java 5 and Java 6 are bytecode compatible but requiring additional compatibility libraries are going to be a problem in the long run. Combining this with the Java security restrictions put in place we can find our self running on a monolithic IBM Java platform which hardly was the idea.

So what’s the answer?

It seems more and more like IBM should support custom JVM for at least the server. It would be nice for the client as well but lets be reasonable. It could a solution where there are a number of choices – some choices could be proven and (absurdly) battle-tested (Java 1.3, Java 1.4.2) and some simply following the industry (Java 5, Java 6). I know it probably never will be possible to simply drop a new run-of-the-mill Sun JVM into Domino but this isn’t necessarily the goal. I simply want a JVM that follows along. It might be that it required an additional download and install but at least give me the choice.

As for the Notes 8 client it might be even easier than for the server since the Eclipse foundation already allows for a custom JVM. Why not support running Notes 8 on an already installed JVM? One could even argue that the client would benefit just as much from a JVM upgrade than the server since the Notes 8 client will be a universal client and hence not simply access Notes data. If IBM expects ISV’s to develop Java solutions for Notes 8 they will expect a common programming model for Eclipse/Notes 8 based solutions which comes down to the JVM.

So IBM – please upgrade the JVM or allow for “custom” JVM’s – soon… Oh – and please upgrade the Notes/Domino Java API – who still uses java.util.Vector? Thank you! 🙂