So the new abbreviation you have to learn is SPNEGO. SPNEGO is a stadardized protocol for single-sign-on (SSO) between diverse systems. The purpose of the protocol is to provide SSO between the operating system and the services you use whether they be on the web or client applications. Basically it means that the credentials of your Windows logon is automatically used and you are logged transparently into any services that are SPNEGO aware (of cause there are provisions for mapping credentials between systems as well).
So what does this mean for you as a Lotus professional?
An easier life is what it will eventually mean. For now SPNEGO can be configured with Lotus Connections since it runs on Websphere Application Server. In fact there was an article on this just recently on developerWorks (SPNEGO TAI: Using single sign-on from Windows to WebSphere Application Server). In the near future you will start laughing as it will be the SSO protocol for Notes 8.5 and maybe even for the Domino HTTP server as well.
This will mean better ease-of-use for users and it will mean a dramatically lowered TCO for Lotus technology as all Lotus products will be able to use industry standard SSO technologies probably even without additional costly SSO software.
How do you like them apples? 🙂
In my post titled “XPD – where do you live?” from the other day I discussed some problems with i18n (internationalisation) of applications developed in Java for the Notes 8+ platform using the built-in classes (java.util.Locale). Since that post I have been in dialog with IBM via the Domino NEXT Design Partner program.
It has been confirmed that this is indeed a problem and probably in the core Notes client. The problem probably stems from Lotus Expeditor.
Unfortunately not much light has been shed on the subject except IBM asking me to run a Danish Notes client which is among the worst thing I could imagine doing. I run software in English – period! I do however expect the software I run to be able to detect my computer locale as set in the operating system. As an aside it is actually quite common for non-English speaking Europeans to run English software despite the fact that a native-language edition is available.
As part of this process I have been thinking about the API’s that we need to have available for i18n. It is quite clear that we need
- the possibility to obtain the language (as a java.util.Locale) of the client itself (that is the language of the menus etc.)
- a way to obtain the java.util.Locale the OS is configured for
- an official API for accessing the regional settings as configured in the Preferences for the calendar display in Mail
If we had these we should be able to create the kinds of localized products and plugins customers expect and demand.
What is your take? Can you see more API’s we need while we’re at it?
Disclaimer: I’m trying to get some info from IBM on this subject so please check back as I will update this post as more info becomes available…
Again this is one of those posts that will annoy the heck out of European developers…
Internationalisation – or i18n – is done using the java.util.Locale class in Java. When calling Locale.getDefault() the standard Locale for the JVM should be returned and should be da_DK for me (country: Denmark, language: Danish), en_US for you US guys (country: USA, language: English) and de_AT for people from Austria (Country: Austria, language: German). The Locale can be supplied to many localisation sensitive classes such as java.util.Calendar etc. to make sure it works as expected for the current user locale. Most times however you don’t supply the locale explicitly which will make the platform do a Locale.getDefault() for the current locale.
Meet Lotus Notes 8+…
Per default Lotus Notes 8+ runs with a Locale of en_US which is great if you’re based in the USA and speak English or simply only use the built-in functionality of Lotus Notes. If you’re a plugin developer and you do any i18n work you will be sadly disappointed since Calendar and ResouceBundle will be broken. Since Locale.getDefault() returns en_US you will get back a Calendar for the US (e.g. Sunday is first day of the week) and English strings from your resource bundles.
Maybe this is why the preference has a page for locale setup (see File/Preferences/Calendar and To Do/Regional Settings) which is used by Mail.
To makes matters worse I think it’s a core platform issue since you can actually change the language of your Notes client by supplying a command line argument (-nl) to the Notes client. Doing this (-nl da / -nl da_DK) changes the menu item text in my Notes client but any plugin that use Locale.getDefault() still return an incorrect result as shown on the image below.
To make it even weirder it works as expected when the Notes client is started from the Eclipse IDE using “-nl da_DK”. Go figure!
(click on the image for larger version)
This behavior has been verified with Notes 8.0.1, Notes 8.0.2 and Notes 8.5 beta 2.
Last night I stumbled over an amazing article on the developerWorks site and it’s just fantastic. Not that the articles normally aren’t good but this article introduce a Lotus Expeditor tool that could prove invaluable for many Notes 8 shops for use in Notes 8 training or for use in Notes 8 plug-in development. Although the tool was written for Lotus Expeditor it installs just fine under Notes 8.0.1 without any problems at all.
The tool is called the Personal Wizard plug-in and is, from what I can see, developed by Vittorio Castelli from IBM. The tool allows you to record user interface interactions in the Lotus Expeditor/Notes 8 client and play the interactions back. Either by you or by another person you send the procedure. You can also save/load procedures to/from the filesystem.
In this way the tool can be used to automate test procedures and as a way to create end-user education. The tool allows you to step through a procedure (useful for education) or run it as a macro which is useful for development/testing. The tool is a little rough around the edges but it is definitely worth a look.
Using the Personal Wizards plug-in in IBM Lotus Expeditor
“Have you ever find out that you spent 3 days in something that could be done in 3 hours? Or maybe you just missunderstood some part of the documentation? Well, this space is created to avoid that. The main goal is to have a repository or Configurations, Workarounds and Technotes of the Lotus and WebSphere brands but from the user side. Documentation is the base, experience is the key.”