Bob Balaban's Blog


    Bob Balaban


    Do we need new kinds of replication?

    Bob Balaban  April 22 2008 06:55:00 AM
    Greetings, Geeks!
    Today I wish to talk about a favorite topic of mine, Notes-style Replication. We all know about it and love it, naturally. It's one of the great foundational pillars of Notes and Domino, it's value to the product and to the applications built on the platform cannot be under-estimated.

    BUT (I claim) it is time to start thinking about the need for an enhanced replication facility for Notes and especially for Domino.

    The need (I claim) for a couple of new kinds of Notes/NSF replication has been around for a while, as I'll explain. However, I think the need will accelerate in the next 1 or 2 releases of Notes/Domino, if people (Developers, mainly) start really embracing some of the new features that have appeared in N/D v8.0, and which are likely to appear in v8.5.

    What "new kinds" of replication am I talking about? Two, mainly:
        1) Multi-NSF "packages"
        2) Non-NSF files in the N/D data tree

    Multi-NSF applications have been around for years. The very first consulting project I worked on after leaving Iris Associates in 1997 involved distributing data across as many as 7 Notes databases per dataset. The reason, of course, was that (at the time, in V4.6)  the maximum allowed size of a single NSF was something like 2GB (it might have been 4GB, I can't remember specifically). And databases larger than 1GB led to pitifully poor performance. Aside from the difficulty of coding and app set up like that, the fact that a given installation required several instances of an NSF to replicate all at once meant severe headaches, both at application install time (setting up multiple replication instances across a few servers, and ensuring that all the app NSFs replicated at the same time), but it was a headache for the admins, too. They had to know either not to touch ANY of the NSFs in a given group, or to apply certain kinds of changes to ALL of them, at once.

    The other type of "replication" that I mention above is also not terribly new. Ever since Domino became an HTTP platform (1996 or so, with V4.5), developers have been storing pieces of their app as HTML files in the "data tree" (domino\data\domino\html, and associated folders) on disk, instead of "inside" NSF files. My extensive research shows (Ok, I called a couple of people...) that there were (are) two reasons for this:
        1) Simplicity of referencing with HTML links. Domino-generated URLs were then, and are now, rather complex to deal with. But if you put an HTML file in a certain place on the server disk, you always know how to reference it.
        2) Performance. I am told by a reliable source (they guy at Lotus who actually maintains the HTTP server code) that it's 2 or 3 times faster to serve a file off of the server's disk than it is to serve the same file embedded somewhere in an NSF (on a Page, perhaps, or as a file resource). This is especially true because in more recent versions of Domino, the amount of caching that the HTTP server tries to do on disk has been scaled way back.

    Ok, so you have a Domino Web application that relies on specific files on disk. Replicating the NSF (the major piece of the app) to another server is no big deal, but how do you install and/or keep non-NSF files synchronized? There are ways (run a scheduled agent that can access a mapped drive to another server and copy files, buy a third party utility that does it, write an agent to detect modified disk files, attach them to an NSF, replicate, then have another agent detach newer files to disk, etc. None of these solutions is particularly satisfying, especially because none of them (that I am aware) handles merges and conflicts very well.

    So I think we'd all pretty much agree that this issue is not a new one. So why bring it up now?

    I'm mentioning it now because I see the need for a solution becoming more important, not less. There are two sets of enhancements (one released in v8.0, one coming in v8.5) that will potentially cause this problem to become even worse, in the sense that more people will require it. The two new features are:
        1) Composite Applications (released for Domino in v8.0)
        2) Dojo JavaScript libraries shipped with the Domino Server (scheduled for v8.5, this year).

    The pressures on multi-file replication are clear: CompApps involving Notes-based components pretty much require you to use multiple NSFs. The "Application" database itself has almost nothing in it, except some attached XML files that define the CompApp. There will be references in there to 1 (or possibly several) additional NSFs containing data and/or logic components that make up parts of the overall application. At application launch time, a Notes user double-clicks on the icon representing "the composite application" (the mostly empty one), and the right thing happens in the Notes Client - the multi-pane window opens up and the right components appear in the right places. BUT, it only works if ALL the referenced NSFs are where they should be.

    I've had many experiences of trying to open a CompApp that was replicated to a server that was not the one used to originally install the app. If one database comprising part of the overall app is not replicated, or if it is replicated to the new server, but to a location different from its originally referenced one, stuff is broken.

    Furthermore, go tell a Domino server administrator (even an experienced one) that you have a Composite Application on ServerA that needs to be moved (or copied) to ServerB, with replication enabled between the two instances. Go ahead, I dare ya! This exposes another, related problem with multi-NSF applications -- you can't easily figure out from looking at the "main" NSF in a Composite Application what OTHER NSFs are required to make the app work, unless you're willing to go read some XML files or poke around in Domino Designer, looking for database references. Yet, the whole group of them MUST be replicated as a unit, and must follow the original folder layout, neither of which is generally a requirement for "traditional" Notes replication.

    The second new featureset, scheduled to appear in v8.5, is a terrific enhancement for developers working on Domino-based Web application development. Shipping a set of Dojo JavaScript libraries with the product (and exposing easy ways of hooking those libraries into your app via Domino Designer) is a huge step forward for Web apps on Domino. Dojo is a popular, browser based set of JavaScript code, distributed as open source. It provides some very nice features to the Web application developer, among them: browser isolation; sophisticated AJAX support; accessibility features; a full complement of UI widgets, from which a JavaScript developer can inherit and customize new widgets, and so on.

    Now, for performance and other reasons (as mentioned above), the plan (which could, of course, change at any time) is to ship the Dojo libraries as a set of .JS files on disk. This will work great if your Dojo-enabled Web apps all run on newly-installed servers, all of the same release of Domino. But if not, then you may have a problem. Let's say (hypothetically) that Dojo version 1.2 ships with all Domino 8.5 servers, on all OS platforms. Then let's say that Domino 8.5.1 is released with Dojo v1.3, which has some nice bug fixes and/or new features in it. Now let's assume that I've deployed an 8.5 Web App using Dojo 1.2 on one of my new 8.5 servers. If I have a second server that gets 8.5.1 and I want to now deploy my app there, I could have a problem.

    I now need to pick not only which version of the server I should QE my app for, I have two different versions of Dojo to deal with, too. Do I pick one or the other? If so, how do I get the 8.5.1 version of Dojo (hypothetically v1.3) over to my 8.5 server (which normally only has Dojo v1.2 on it)? PLUS, if I've deployed pieces of my JavaScript based client as .JS files to disk, how do I synchronize those between the two servers (or between any 2 servers, even if they are running identical versions of Domino and Dojo)?

    My point is that, although I think Dojo is a terrific enhancement for Domino, using it will increase the level of deployment complexity and synchronization complexity for both developers and admins.

    An enhancement to the way Domino does replication to include non-NSF files as well as to be able to treat a collection of related NSFs as a unit would be very, very helpful (Note: Of course I am not naive enough to expect that non-NSF file replication could have all the features of NSF-to-NSF replication, but that's a topic for another post...)

    (Need expert application development architecture/coding help? Contact me at: bbalaban,
    This article ┬ęCopyright 2009 by Looseleaf Software LLC, all rights reserved. You may link to this page, but may not copy without prior approval.

    1Henning Heinz  04/22/2008 9:58:14 AM  Do we need new kinds of replication?

    Maybe working on the 2 to 3 times slower feature of nsf stored data would help too but I know I demand too much.

    2Erik Brooks  04/22/2008 11:01:08 AM  Do we need new kinds of replication?

    I'm glad you asked these questions. :-) I've been wondering for months how IBM was going to handle Dojo distribution in 8.5., since it would likely be on-disk in the filesystem.

    I believe that the 1.x.a releases of Dojo should all be compatible with 1.x.b, but obviously once 1.y is released that could all go out the window. We'll see what IBM decides to do.

    My guess is that they'll ship ALL prior supported versions of Dojo as they release new versions of Domino, similar to how DXL's "domino.dtd" files work. I would guess that some server doc(s) settings will control the actual hooks into the library, so that as new hooks are added and old ones evolve, you can change out frameworks as needed. We'll see.

    3Gerald Mengisen  04/22/2008 11:19:14 AM  Do we need new kinds of replication?

    Very good points and if replication was enhanced to support multi-NSFs and files, that would be very useful.

    The Dojo version conflict on the Domino server could be solved by putting Dojo into a directory that includes the version number in its name, e.g. Dojo_1.2. Then Domino 8.5.1. would keep Dojo_1.2 for backwards compatibility and would add Dojo_1.3, and 8.5.2 would add Dojo_1.4 (and maybe get rid of Dojo_1.2) . That way the developer can change the paths to the new Dojo version once all servers are upgraded and the application has been tested under Dojo 1.3. In fact, that path could be stored in a shared computed for display field and distributed via design task to all applications that need it.

    4Gerald Mengisen  04/22/2008 11:21:02 AM  Do we need new kinds of replication?

    Erik's post wasn't there yet when I typed my reply :-)

    5Edith Birrer  04/23/2008 2:17:54 AM  Do we need new kinds of replication?

    Makes a lot of sense, especially for composite apps and for multi-nsf-applications. But for the latter there should still be the possibility of having only one or some of them replicated and one or some of them only being on one server (e.g. the less used ones stored centrally). If one uses the replica ID instead of relying on a specific path, most of the path-layout problems can be addressed by the developer. That's what we have now, but I agree that a possibility to define database to belong to nsf-groups would definitely simplify things!

    6Bob Balaban  04/24/2008 7:15:25 PM  Do we need new kinds of replication?

    @1 - I'll pass your request on to the Domino team... :-)

    @2 - Your guess is as good as mine, Erik, but I would not be surprised if you are very close to being right :-)

    @3 - Hi Gerald, hmmm.... good idea! Maybe someone from IBM is following this thread...

    @5 - Thanks for the feedback, Edith!

    7Peter LaComb  05/05/2008 11:12:51 AM  Do we need new kinds of replication?

    For those of us on a windows platform, non-NSF replication can be handled by Windows DFS, so long as we're talking about a folder that doesn't have NSFs in it (as in the data\domino\html, etc).