Here's an interesting article on using Outlook from orbit.

In a nutshell, they build an OST for Outlook on the ground, copy it up to a fileshare on the Shuttle, where the astronauts then use it to handle their email.  The saved OST (presumably with mail in an Outbox) is then copied down and handled elsewhere.

 

In one sense, this is a wonderful hack.  A glorious kludge that gets people their email in adverse conditions.

 

In another, this is ludicrous.  It's forcing Outlook to do things it was never designed to do, and has all kinds of issues because of this.

 

Frankly, I can think of better ways of working remotely.  Naturally, my first suggestion would be Notes - just replicate, baby!

But then, there may be latency issues - which would mean that the fewer actual TCP requests, the better.

Replication may be efficient, but there are many small requests in there, so high latency would suck.  Given the potential for loss of signal too, replication is probably better than POP3/IMAP over the link, but not as good as a file copy - because if you copy one big file, then just about every packet in the send/recieve is nice and full.

(Even copying many small files via rsync/robocopy will generate many small findfirst/findnext requests to the filesystems, so is probably not good.)

 

Given that's the case, set up a little SMTP/POP3 server.  Connect Outlook to that, and work locally within the Shuttle.  Then you can sync with the ground by using tar/gzip on the POP3 server files and the SMTP server queues.  It'll likely transfer a lot more data in a much smaller file than an OST, too.

 

Aw, heck.  There are loads of ways to do this.  After all, UUCP and FidoNet had this licked years ago in the days when everyone used text consoles, and graphical interfaces were a pipedream.

 

But copying an OST - well, it smacks of the kind of rush project that everyone dreads, the "temporary fix" that becomes permanent.

 

NASA IT - not somewhere I'd like to do messaging right now!

 

If you're going to note something, then note it well.

 

So I apologise for the sudden rush of blog entries, but this 20th "birthday" of Notes is something which should be handled properly.

A 20th birthday requires a decent dram, at the very least.  And it just so happens that one of my favourite drams of late is also 20 years old...

 

Well, it'd be rude not to, wouldn't it?

 

Pittyvaich "Limited Edition" 20yo

A limited release of only 6000 bottles, each bottle individually numbered. Bottled at 57.5% abv.

Pittyvaich was built in 1975, to supply the Bells blend.  Closed in 1993, but mothballed and used for some odd experiements (including, it is rumoured, making gin!).  This distillery does not have a high profile, and not many bottlings of it have been made available commercially.

 

Nose: Light oranges, pineapple, grass, perhaps a metallic note. With water, the metallic note disappears and a trace of soft supple leather emerges.

Body: Crisp. sharp, zesty and clean.  Fresh green apples, more oranges.  A light cereal note, somewhat biscuit-like.  Also a little acidic.  With water, the green apples slide into the background and the cereal and orange notes come forwards.

Finish: Zinc, salt.  Quite sharp, but lingers and slowly lets out more of that sweet orange note that was present in the body.  With water, a little spice joins the orange note - perhaps cardamom?

Conclusion: A fine, potent and robust dram.  Amazingly youthful for a 20yo whisky.  It's great at its natural strength, yet incredibly potent.  But if you want to add water, it'll work with it all the way down - it keeps changing and shifting its balance of flavours without ever actually losing its core character.

A truly fine whisky...

 

Let's just remind us why I'm on this fine dram:

Lotus Notes & Domino 8.5 (General availability)

A general release of 145 million licenses sold to date.  Initial release in 1989, but new releases have been available roughly every 2.5 years.

Still in production, with no signs of going away (despite the competition's best hopes!).  We were unable to measure the strength of this release, as it broke our gauging equipment - something stronger is now on order.

 

Purpose: Defines "groupware", but with hints of email communications, collaborative working, remote working and replicated distribution of data.  After time, adds in some further abilities for connecting people.

Capabilities: Email, discussion, workflow, replication and mutiple platforms are all in the early impressions.  After time it reveals stronger development capabilities, web serving, SMTP mail, integrated instant messaging, and a strong platform for composite applications.

Impact: Lower total costs of ownership than competitors and yet also greater capabilities.  After time, flexibility and rapid development shows a real benefit.

Conclusion: Twenty years has matured this nicely, and yet it's not stood still and shows no signs of premature ageing - nor has it lost sight of its core strengths whilst adding in newer capabilities.  It's always capable of surprising you, and with a recent investment in a new production platform it will probably continue to do so even more.

Truly fine software...

 

 

Here's to Twenty.  A good age for whisky.  A good age for software.  Just don't mix the two in a production environment, folks!

 

Sorry for the extended silence recently.

I've been a bit busy, and didn't have time for the next entry I was going to write - on Exchange and ESE.

 

I'm now on annual leave for two weeks, "busy doing nothing".  Hopefully, that will include turning various notes I've written into something structured and readable!

 

Notes 1.0 was released today in 1989.

I first met Notes at around R3, a short while before R4's release (if I recall correctly).

It's funny to think how much Notes has changed in some ways, and yet how much of it is the same.

 

Proven.

 

That's the word you're looking for when you talk about Notes.

 

Lotus Knows Proven.

 

I've been wanting to ruminate on NSFDB2 and its fate for a while, and have finally decided to do a braindump.  Apologies to my more expert readers for the gentle "beginner's introduction" start, but this all does have a purpose...

 

It was back in the R7 days when we got our first sniff of Notes and DB2 (NSFDB2).

It was a new technology, and IBM were justifiably both proud of it and at the same time cautious.  When you change a storage engine, you want to be careful.  So for the whole of R7's lifespan, it was something you had to ask for specifically from IBM.

This wasn't a huge issue, but probably seemed odd to many.

DB2 integration had some specific goals, mostly around handling very large data sets.  The idea was to combine the strong RAD environment of Notes - and to an extent its looser normalisation and data typing - with the high performance and scalability of DB2.

That was misunderstood a little at first in the Notes community, and some were disappointed that they couldn't just throw their 2,000 mail databases into a DB2 store and get a free performance improvement.  It was soon clarified that it was primarily for apps, not mail, which helped.

In R8, the integration was improved somewhat and the feature was open to all - you no longer needed to ask IBM for a feature key to use it!

It seemed that NSFDB2 integration had come of age.

 

Which is why it was a bit of a shock when IBM announced that support for NSFDB2 would end with Domino/Notes 8.5.

There wasn't a lot of wailing and gnashing of teeth, but that's mostly because there were very few deployments of NSFDB2 - it was still a very new technology.

It could be argued that IBM did the right thing when they killed it early - rather than struggle on with whatever difficulties they had with it

But what wasn't terribly clear - to me at least - was WHY they killed it.

 

IBM said at the time that it had been very difficult to get non-relational data into DB2, and make it perform as they'd like.  And that the future for Notes was NSF, which would continue to be improved.

But this was a brief note, buried almost immediately by IBM throwing options out as to what people could use instead - from DECS to LEI, and third party tools like Notrix.

I can understand being more keen to advertise the way forward rather than dwell on the unpleasantness of a feature lost - but I like reasons!

 

So here I'd like to speculate wildly for a while on why DB2 was axed.

The following is my inference and reasoning from the limited information available.  It is not canon. Thank you for remembering that!

 

I believe that with NSFDB2 there are three main considerations IBM had.  The first was support.  The second was ROI.  And the third was politics.

 

Support is easy to explain.  Even when in its final release form, DB2 support was missing on some supported Domino platforms (Solaris,  iSeries and zOS and others) for periods because either DB2 on those platforms is singificantly different, or the DB2 libraries weren't available on the platform.

And then it gets more painful because by tying the two products together, IBM is effectively committing to supporting one for as long as the other.  That's not necessarily desirable in all circumstances.

Worse, it may be that newer versions of one product can't support the newer version of another without a delay.  That's not good..

The only way to effectively support this over the long term is to synchronise the development, testing & release cycles of the two products.  Anything else gets messy.

But I see the real problem being that the two products work in very different markets.  DB2 shouldn't have to wait for Notes releases in order to ship Oracle-killing features.  It should be able to strike whilst the iron is hot.  And the same applies in reverse - Notes should ship when ready, not when DB2 is ready with Oracle-killing features Notes may not even use.

And this is all support from IBM's point of view.  I'm not even going to go through the pains of support for customers (architecture, installation, patching, etc.).

 

After looking at support issues, ROI becomes obvious.  A lot of investment was put into NSFDB2, and the actual ROI was vague.  Yes, some very large apps became faster - but other paths had been available for similar performance gains.  And it wasn't something you'd typically use for mail, which is the vast majority of Notes/Domino I/O cycles worldwide.

The ROI on NSFDB2 just doesn't add up favourably for IBM.  Even if you argue that it's a strategic investment, it will probably take a decade or longer to give decent returns.

 

But finally, politics might be an issue some people didn't quite realise.

Not internal politics at IBM.  (I know nothing of such things!)

The politics within their customers.

NSFDB2 gives you relational database advantages with one database only - DB2.  It looks like a play for space in the data center to some.  And implementing it has overheads - you can imagine the CIO looking at this, and asking why it must be DB2 when they have trained Oracle or MS SQL DBAs on hand.

I suspect that the takeup of NSFDB2 was hampered by this kind of politics at many customers.  Even if the DB2 install had been completely turnkey, there would be a fear that it's more licensing, more training, more complication on the infrastructure.

Basically, many people probably suspected it was a "back door" entry for DB2, and that's the kind of thing that can play very badly with management - who are holding the chequebook!

If the applications need that level of performance, then why not just use J2EE or .NET, and put the data in an RDBMS natively?  Much more politically acceptable, much simpler to architect and support - even if it may actually be more expensive...

 

That is why I think NSFDB2 died.  It was a complicated abstraction that served less than 1% of all NSF requirements, and even then didn't quite serve it in as transparent and simple a manner as we'd ALL have liked.

Given the differences in the products, it was a magnificent achievement to even get it to a level where it could be shipped.

But from customer to Notes geek to IBM, all realised that a relational database behind NSF just wasn't as good in reality as it looked on paper.

So IBM decided to improve NSF, and we can see that happen with R8.5 and DAOS.  Which, overall, is far more important to the Domino/Notes installs worldwide than DB2NSF ever could have been.

 

These thoughts, by the way, are a prelude.

In my next entry I'm going to cover Microsoft Exchange Server, ESE and SQL Server.

I didn't want to be accused to covering that tricky subject whilst glossing over the "failure" of Notes to move to a new database engine.  But I think I've been more than fair here, and can therefore also be more than fair tomorrow...

 

	Articles
	Blog entries
	Comments