Erik Brooks

So, I'm reading blogs this morning and on Ed's blog I see the following Twitter:

"Google announces offline mail support for gMail.  Wow, Domino Offline Services was only 10 years ahead of its time!"

True.  But: How many people out there have used DOLS?  How many people reading this blog have used DOLS?  I have.  I'd bet large sums of money that I have one of the most complex, multi-NSF Domino web apps in history running on DOLS, with quite a bunch of distributed users.  And based on a couple of DOLS-related support tickets that I've had to open, I'm pushing the envelope with it.

In my opinion DOLS is (and has been) the greatest unknown secret of Notes/Domino.  DOLS can allow users to access their mail offline in their browser, yes.  But it can do that with ANY OTHER Notes/Domino databases, too.  It's fairly easy to set up and administer (though it could be easier), is fairly easy for users to work with (though that could be much easier, and *this* is where Google will likely leapfrog Lotus in the future), and although it has its share of problems it is an incredible tool.

Simply put, DOLS is a packaged-installation of the Domino HTTP server and a small Windows-desktop app for launching said HTTP server to do work offline.  It also has a mechanism for replicating NSFs back to the corporate office.  Your users work in a browser as they would online; they're just connecting to the local HTTP server on the laptop instead of your corporate server.  It's all core Notes, through-and-through, and is a brilliant re-use of existing technology.  Click here to read Damien Katz's similar comments.    If you've got a Domino web app that you want to enable for offline use, it's literally only a couple of hours to put DOLS support into it and try it out.

So is IBM continuing the advance of this fantastic add-on?  It's a bit uncertain. They've kept re-packaging it with each release since its launch (back in R 5.x!) But it has had only minor bug fixes since then, and the release of Notes/Domino 8.5 has a fairly glaring omission: DOLS doesn't currently support xPages offline. 

I wouldn't be surprised if this was a decision of "we gotta ship 8.5, we'll do it in 8.5.x".  I also wouldn't be surprised if it was simply overlooked - the DOLS packaging is so straightforward it probably easily builds automatically whenever a new update is released.  It should be the case that the xPages engine just needs to get packaged in with everything else, and it would Just Work (tm).

With xPages as the obvious future of Domino web dev, DOLS now runs ths risk of becoming a mail-only utility unless it's brought up to the present with xPage support.  If it can't run the new wikis, blogs, discussion databases, custom apps, etc. that IBM and the community are creating its usefulness will be severely diminished.  Then the question becomes: How long will it take Google to extend their offline functionality to other areas, e.g. Google Apps?

The good news, though, is that adding xPages support should be fairly simple for IBM/Lotus to do:  they're already packaging the full HTTP server as it is.  Can you imagine: xPages-enabled Domino apps running offline?  Mmmmmm....

If you haven't yet tried DOLS, check it out.  You will be surprised.

Well, it's coming at least.  Probably.  From the Fix List database:

SPR # DMAT72JLWW Fixed in release: 7.0.4 

Product Area: Designer  Technical Area: LotusScript  Platform: Cross Platform

Lotus Customer Support APAR:  LO28240  What is an APAR?

SPR# DMAT72JLWW - Added NotesDatabase.CreateDocumentCollection method to create empty doc collection.

So it sounds like we'll see this in 7.0.4, due in March.  Which means it will likely make it into 8.0.3 and/or 8.5.1.  I guess we can all get ready to cross another one off of the IdeaJam list!

This blog post is the first of a 3-part series that focuses on some possibilities (some mine, some from inside IBM themselves) that could be a big deal to anybody who cares about view performance. 

Views.

They're the core component of any Domino database.  You may argue that forms are more important, but with xPages you don't even technically need those anymore either.

Views are the only real-time-capable index you can create.  If you need to sort or categorize data with anything remotely resembling scalability or speed, you need views.  As a result we all want them to be fast.  REAL fast.  And we want lots of them, with all the sortable options enabled, and with as many different columns showing as many different pieces of data as possible.

But views are expensive.

One of the best things IBM could do for views (besides adding JOIN capabilities) would be to store view indexes outside of NSFs.

A view "index" is essentially two items, $Collation and $Collection, that gets stored on the view design docs.  Go pull up the document properties on a view design doc in Designer, and you'll see them.  But you won't see the sizes.  For that, you'll need to use the Administrator client.  Simply open the "Files" tab, right-click on your database and select "Manage Views".

If these fields were moved to be outside of the NSFs, then we'd realize some significant benefits:

1. Many NSF sizes would be drastically reduced -- many NSFs have over half of their size allocated to view indexes.  And smaller NSFs perform much faster than larger ones.

 

2. View indexing could be offloaded to separate drives from the NSFs altogether -- even more speed!

 

3. Notes queues writes.  A db is completely write-locked with *any* write that occurs to an NSF.  So while a view index is being written to inside an NSF a doc cannot be simultaneously added to the db, user activity can't be recorded, etc.  With this change this bottleneck could be removed - the view index could be written to externally while a doc is added to the NSF.                            

  
Here's the kicker:  With DAOS in 8.5 I'd bet money that the groundwork is likely already there for abstracting an item out to the filesystem.  View indexes aren't replicated anyway - why store them in the view design doc at all? You could argue that for security reasons they should stay in the NSF, but that's easily addressable by encryption similar to how DAOS encrypts its files.

Sound interesting?  If you're interested, there's two ways to let IBM know that you care: 

1. Open a support ticket with IBM, asking to be added to SPR#: DCOE7N32FM / APAR#:  LO36534

 

2. Go vote on the topic on IdeaJam: http://www.ideajam.net/IdeaJam/P/ij.nsf/0/BA723B6332ED0C67862573B4003E9AE2?OpenDocument

 

Thanks for reading.  There's more fun stuff to come, including an IBM patent that will make some of us Domino people say "WHAT? WHEN?"