Did I mention that I have a second topic I've submitted for Lotusphere 2009? It is about web development ZEN style. ZEN style is when every stroke is meaningful, every line as a function and there is just enough code to fulfill a purpose. It takes quite some practice to get there, so as simple as it looks.... Vote!

Yesterday I mused about how you can add a Domino 8.5 xPages server to an existing Domain without changing the existing infrastructure. Looking at the picture I realized, that while its function seems to be obvious, it actually might only be obvious to the initiated. So I went back to the drawing board. In a typical web application setting using other technologies (like JSP, ASP or PHP) you typically have a web server, an application server and a database server (they can and do sit quite often on the same physical machine). This is well understood by almost all IT decision makers. So for a Notes application web enablement you need a web server. This would look like this:

You add a "Web Frontend Server" to your existing infrastructure. It is like adding an Apache to an Oracle database or MS-IIS to MS-SQL. The nice thing in the Domino stack however is, that you don't need to acquire new skills to administrate this "Web Frontend Server". The box is simply your's truly Domino 8.5

" R8.5 and xPages ante portas!" Not before long and R8.5 will be released and you can deploy the shiny new Domino web2.0 application that created so much buzz. However you can make a safe bet, that your infrastructure team will stop you short: " Not so fast young man, we are not ready". Luckily you don't need to wait for a wholesale upgrade of the entire Domino infrastructure. You just need to add one R8.5 server:

There are a few pointers you need to be aware of:

• The R8.5 server must use the R8.5 templates for all system databases, most notably the Domino directory. R6.5x and R7.0x server work with the 8.5 system templates. If upgrading the system templates is a problem (a real or perceived one) for the infrastructure team, configure replication not to update the design from/to the R8.5 server (you do that by changing the ACLs).
• You need Domino Designer 8.5 for xPage applications. You can use Domino Designer 8.5 to design applications for R6.5/R7.0/R8.0. You just need to test them with the respective client (VMWare and friends are your friend. Or if you got a collection of PCs, use Synergy)
• You must use the Domino Administrator 8.5 to administrate a R8.5 server. You can easily administrate R6.5/R7.0/R8.0 servers using Domino Administrator 8.5
• xPages design elements don't need to be stored in the same NSF as the data. This means that you can design your web application without touching the original NSF design.
• The data sources for xPages can be on a different server. This means you don't even need to replicate your existing databases to your new R8.5 server. However you do want a fast network connection between the two servers. For the R6.5x or R7.x server the xPages application is just another set of users coming in. Of course best performance means local access using ODS48
• Never ever use a lower ODS than you can. ODS stands for On Disk Structure. Domino servers support older version of the ODS. You can use a R5 or R6/7 ODS on an R8 server. But it is not a good idea. The support is meant for the upgrade phase. You upgrade your server, the database then have the old ODS. You run compact and you are good to go (or my favorite: create a new replica). The ODS has no influence on replication. The only catch: you cant FTP a database back on a lower version of the server. This never should be an issue since skilled Domino developers don't FTP, they replicate.

An interesting discussion happened today around Notes performance. In a rather large database (> 500k records) all documents are protected with Author and Reader fields. The access is rather narrow, so any user might see just about 1000 of the 500000 documents. Opening a view in the Notes client is rather slow and the old "rah. rah Notes is bad" song is performed. Notes performance is discussed in great length at other places, so this isn't what this post is about. I was wondering how one would implement access control on a record level in a relational database. This would be the specifications:

• Design a view that restricts access to a subset of table data (we simplify here by excluding multi-value data fields)
• A record can have zero or many readers, who are allowed to see the record
• A record can have zero or many authors, who are allowed to see the record and later update them (eventually)
• If a record has no readers any user with access to the database can see the record
• If one or more readers are present only the sum of readers and authors can see the document
• A reader or author can be of type: Person, Group, Role
• A role can be assigned to one or more Persons or Groups
• A group can contain Groups and People (we simplify here and omit the * operator)
• A group can have zero or more roles
• A person can have zero or more roles
• A person can be member in zero or more groups

Graphically it would look somehow like this:

Now how would an SQL statement look like? I'm not an SQL expert, so I might get quite some stuff wrong. But here is my go:

SELECT* FROM maintable
   WHERE maintable.id IN (SELECT readertable.maintableid FROM readertable
   WHERE readertable.entry = @CurrentUser
   OR readertable.entry IN (SELECT roletable.roleid FROM roletable WHERE roletable.entry = @CurrentUser)
   OR readertable.entry IN (SELECT grouptable.groupid FROM grouptable WHERE grouptable.entry = @CurrentUser)
   OR readertable.entry IN (SELECT roletable.roleid FROM roletable WHERE roletable.entry IN
   (SELECT grouptable.groupid FROM  grouptable WHERE grouptable.entry = @CurrentUser)
   )
   OR maintable.id NOT IN (SELECT readertable.maintableid FROM readertable)
   OR maintable.id IN (SELECT authortable.maintableid FROM authortable
   WHERE authortable.entry = @CurrentUser
   OR authortable.entry IN (SELECT roletable.roleid FROM roletable WHERE roletable.entry = @CurrentUser)
   OR authortable.entry IN (SELECT grouptable.groupid FROM grouptable WHERE grouptable.entry = @CurrentUser)
   OR authortable.entry IN (SELECT roletable.roleid FROM roletable WHERE roletable.entry IN
   (SELECT grouptable.groupid FROM  grouptable WHERE grouptable.entry = @CurrentUser)
   )

And that's without taking into account that a group could contain a group. Looks like a performance pig to me. Luckily in Domino we can use categorized views to make access fast. Of course I'm happy to learn that there are smarter SQL queries around.

I'm running the XPages enablement workshop in Beijing this week. Having to teach other about new functionality guarantees either dispair or insight. Today I had a rather insightful moment. Very often the NSF gets blasted for being a "flat-file-non-relational-whatever" file. When having a closer look at the format however you will realize, that it is a quite amazing part of technology:

• Build to function as a "whatever-you-want-to-dump-into" data store
• Build backward compatible. I still can open R2 databases in my R8.5 client
• Build to run on a client and on a server with high concurrent access
• Build to be robust: event if you tourture it (diskspace, sectors etc.) it will mostly recover
• Build to provide fulltext search access
• Build to be what you want it to be: if you happen to be a Notes client or a Domino server, it is a repository for design elements and a document database. If you happen to be the Eclipse IDE (or a webDAV client) it is a file system. If you happen to be the XPages server task it is a WAR application store. And if you happen to be David Allen, it is your trusted system for Getting-Things-Done