The DSAPI is a very powerful feature of the Domino server where you can create filters that modifies the Domino web server’s behaviour when processing web requests. However, being a C/C++ API it is somewhat unaccessible to web developers like myself. (Personally, I haven’t done any C++ for 10 years). However, my experience is that the biggest hurdle is acutally to set up the development environment, not the development itself. After a bit of struggle, I was finally able to set up a project in Visual Studio 2005 so that I could develop my desired DSAPI filter. In order to (hopefully) save anyone else from having to waste precious development time struggling Vicious Studio, I have set up a project that you can download here. (Note that I have removed all Lotus C++ API header and library files from the project in order not to violate any copyright legislation. You need to download the Lotus C++ API Toolkit for Notes/Domino 7.0a package and then copy the necessary files into the Visual Studio project).
Basically what I did was creating a new Visual C++/Win32 Console application where I during the project creation wizard set application type to ‘DLL’ and checked the option to ‘export symbols’. Then I created a subdirectory on the file system which I named ‘dsapi’. I then copied the header files and the ‘notes.lib’ file from the Lotus C++ API Toolkit for Notes/Domino 7.0a distribution into two subdirectories of the ‘dsapi’ directory, ‘Includes’ and ‘Lib’, respectively. Furthremore, there was a lot of configuration properties that needed to be changed:
- C/C++ -> Code Generation -> Runtime Library: Set it to ‘Multi-threaded (/MT)’.
- C/C++ -> General -> Additional Include Directories: Added ‘$(ProjectDir)dsapiInclude’.
- C/C++ -> Precompiled headers -> Create/User precompiled Header: Set it to ‘Not Using Precompiled Headers’.
- C/C++ -> Preprocessor -> Preprocessor Defintions: Added ‘W32’ to the list of definitions.
- Linker -> Input -> Additional Dependencies: Added ‘$(ProjectDir)dsapiLibnotes.lib’.
Once these steps have been done, the DSAPI module finally worked!
Once upon a time there was this platform renowned for its security features.
But as the platform became of age, the security features was woven into a large
quilt with considerable number of patches. And then chaos arise.
Domino has a lot of nice security features. It has its own public key
infrastructure, encryption, access control, etc. However, there are a lot of
features that need to work together. Lots of security settings generates
complexity. And complexity is the greatest foe of security.
Take, for example, agent security. In R6, agent restrictions may be set on
each agent instead on each server. This generates more complexity as each and
every agent would have to be administered security-wise. An agent has three
runtime security levels:
- Do not allow restricted operations
- Allow restricted operations
- Allow restricted operations with full administrative rights
One particular agent of mine needed to access the file system on the server,
which is a restricted operation. So, I set the runtime security to level 2.
But, what the documentation fails to tell me, is that there is a setting on the
server document that overrides this. In order for user to be able to run an
agent performing restricted operations, not only has the agent security level
to be set correctly, the user also needs to be listed in the “run restricted
methods and operations” field in the server document. I guess Lotus added this
feature for flexibility. But flexibility is often perpendicular to simplicity.
And when it comes to security, simplicity is king…
Last few weeks I’ve been back on the horse doing Notes/Domino programming
after been working on various J2EE-projects for a couple of years. And I have to
say that Notes/Domino still amazes me. Why? Swift development. Swift deployment.
Swift change. In my opinion, Notes/Domino fits particularly well when you are
doing prototyping: creating an initial version (or Proof of Concept) of your
application is very quick, allowing to present an initial version to your users
in order to collect feedback and change requests. Furthermore, the
Notes/Domino’s unstructured data model allows your application to be easily
changed during its entire life cycle. Being able to change is what agility is
all about. Put that in your pipe and smoke it. 😉
On the downside, automated unit testing of a Notes/Domino application is very
difficult because of the lack of tool support. Because of this, development
methodology like Test Driven Development (which I am a big believer in) and XP
is hard to do.