Domino 10 for Developers

Tue Oct 09 13:17:06 EDT 2018

Tags: domino

So Domino 10 is upon us, marking the first time in a good while that Domino has had an honest-to-goodness version bump.

More than anything, I think V10 is about that sort of mark. Its primary role in the world is to state "Domino isn't dead" - not exactly coming from a position of strength for the platform, but it's the critical message that HCL has to sell if they're going to be viewed as anything but coroners.

Still, in addition to merely existing, V10 brings some changes that will help developers, particularly those - sadly - maintaining large legacy applications.

DQL

The addition that will have the largest immediate impact on developing codebases is, I think, DQL. I went into a bit of detail on this before and I think that that post is largely accurate, but the general gist of it is that DQL can be thought of as "database.search(...) but good", bringing practical arbitrary queries of non-FT data to Domino.

In its current form, it feels like a long-back-burnered passion project that's implemented in an effective way, bringing some of the benefits of arbitrary queries in SQL and new-era NoSQL databases without having to rewrite NIF or NSF storage.

UpdateAs Karsten Lehmann kindly pointed out, DQL is slated for addition to the LS/Java classes in 10.0.1 at an as-yet-unspecified time.

HTTP Methods in LotusScript

I just let out a heavy sigh after writing that header, but I get why they added these. A lot of Domino developers never left the desiccated-but-comforting embrace of LotusScript or are employed primarily to maintain Notes client apps, where using Java is possible but involves jumping over hurdles.

Network operations have been possible for a long time via OLE (on Windows) or LS2J, and I'm sure I'm not the only one who's had a "Network" LS script library sitting around for over a decade, but having baked-in methods is preferable. Moreover, neither of those mechanisms would work on iOS without a lot of additional work.

This is being billed as enabling all sorts of integrations, which I suppose is strictly true in that it's a bit easier to call HTTP methods in old code now. In practice, I think it will be mostly helpful for the little one-off situations where you have to call some web service to integrate with a product tracking app or the like.

iPad Notes Client

This definitely seems like another back-burner project that was brought to the fore in the HCL transition. They had iOS references in the Mac 64-bit C SDK years ago, and it only makes sense, since the existence of the Mac port at all meant the job was (sort of) half done. It's not out today, but it's logically tied to V10, and they've been expanding a beta over the summer.

Like the additions to LotusScript, it makes sense. I can't imagine that running existing Notes apps on an iPad will be a good experience, but it should be a cheap one, and it'll probably be good enough for at least some cases. They've intimated that there will be affordances in app design to improve the experience specifically for this client, though I don't envy the engineers who have to go in and implement those.

Node.js Support

Dubbed the "App Dev Pack", Node support will be coming in an Upgrade-Pack-like additional download, in the form of a Domino server addon to add a gRPC server combined with a domino-db Node module that I gather is designed to be familiar for Node+MongoDB stack users.

When this intention was first announced, I think that a lot of Domino developers figured it would be like XPages: a new design element or two added to the NSF, plus another runtime crammed into Domino's aging HTTP stack. The other big potential option was essentially a codification of the ExtLib DAS REST services into a wrapper package to be used in standalone Node apps.

The App Dev Pack is more the latter than the former, but the use of gRPC should make it more performant and flexible than just wrapping the existing HTTP services. I'll be curious to see how this shakes out in practice. XPages has been with us for a decade, but it still only captured a slice of the Domino development market, and it carried the advantage of being bundled right into the stack. Node is a very different beast, entirely unlike traditional Domino development, and I'm not sure how many existing Domino developers will make the transition. Ostensibly, one of the main benefits is to also attract new blood, which - well, maybe.

Having this is much better than not, and the notion of having a new RPC connection that doesn't have the local runtime requirements of NRPC is tantalizing.

Overall

Overall, this release definitely feels like a very pragmatic release. Just by virtue of its existence, it covers the base of "Domino isn't dead" in a way that's much better than the older mealy-mouthed messaging of "well, we don't have specific plans to cancel it". Additionally, though, the fact that most of the developer-facing improvements are for "old world" design elements is an acknowledgement that XPages didn't capture the Domino development world (and, probably, that HCL didn't hire the XPages team). The prospect of the community crawling back into the LotusScript cradle isn't great, but there's no avoiding the fact that there are a great many developers who never had a reason to do anything different. Not many cost-cutting IT departments let their developers re-learn their entire skillset when other departments are just asking for a new button on a form.

In an alternate universe, this would have made for a fine "Domino 9.5" release, but the wringer that the 9.0.1 era put us through demanded a full major version bump. I'll be curious to see how Domino 11 and so on shape up. If the "not dead" push works and it turns Domino's fortunes in the market around at all, it would give HCL room to turn it into a real platform again. That's a big "if", since it's a lot easier to get existing Domino developers excited than it is to get IT purchasers to sign the licensing checks, but time will tell.

Commenter Photo

Patrick Kwinten - Tue Oct 09 14:20:13 EDT 2018

yes everybody looking forward to Dominov11 to see if that version will make a difference. in the meantime I am curious to learn node.js

Commenter Photo

Wayne - Tue Oct 09 16:49:12 EDT 2018

I'm glad that HCL continues to augment Lotus Script. I'm more an administrator who has had formal program education. I like that i can build a form, a view and have 80% of a functioning application in minutes. I'm not looking to build the next facebook, I want something that allows me to replace that Excel App that gets mailed around with something functional, secure and manageable. Some when in IBM they forgot that and began to throw anything at the platform looking to boost it up, which sounded nice, but in the end did nothing to address the basic concerns that surfaced in the forums in every iteration of the Notes client.

I'm also happy about the "App Dev Pack" as there are several Javascript dev tools out there with plenty of new development methods, React, react-native and Flutter look very promising.

For some this maybe not the best start, but it is a good one nonetheless.

Commenter Photo

Rami - Tue Oct 09 20:27:41 EDT 2018

I am elated with the introduction of node.js with Domino. I am a IBM Cloud developer(Cloudant/node/angular) now but still build xagents with SSJS to surface API's to legacy domino applications.

Domino code is difficult without git and 70% of our dev team a black box. domino-db module should open a new world to our development team that is managed in git and reviewed by all. Also make debugging a ton easier in a decent tool like vscode.

I hope DQL represents a dynamic and performant index to domino.

Commenter Photo

Merlyn - Wed Oct 10 13:02:15 EDT 2018

One thing you can tell, Ray Ozzie and his old team did not design any part of this new stuff (of course). Just like Xpages, this still feels like it's an add-ons approach rather than embedded integrations. That vision is long gone and replaced with the barnacle-ware approach.

Web development in Domino should be natively embedded in the design instead of slapped on top. At the end of the day we have views, forms, pages, actions, search and agents. All we needed was to "Notesify" Javascript with a core stack of JS classes, and "Webify" LotusScriupt with new classes, methods and properties, then some fundamental WYSIWYG web presentation added to the existing web UI.  That is how Ray would have done it. It is evolutionary rather than revolutionary.

There is a saying that the Bill Gates approach is to ask engineers to make it work, then ask designers try to make it look good -- and Steve Jobs approach was to hire designers to make it look good, then ask engineers to make it work. I have no idea if that is a true assessment of those great men, but most of the reason's users dislike Notes was the way it looked "outdated". I disagree about that perspective and its value as a criteria, but users spend tons of hours looking at "modern" app UI's and then have to transition to a different look, and it bothers them. So one of Xpages main appeals on management's radar was that could make apps look "modern". While many of us can do that with classic Domino, most developers can't without "frameworks" and "themes" etc. But Xpages radically changed how the apps were developed. It was abandoning the past.  

I think a better approach was the "Bill Gates" approach, that is improve the foundation functionality and then make a "modern" UI possible after the fact. Essentially, hire the best engineers and designers to improve and build upon Domino's legacy rather than fundamentally changing how we build the apps.

So, why not provide more design elements? Add more ways to dynamically fabricate a UI by combining and manipulating all existing design elements using LotusScript, HTML and JS. Improve the API's and add new ones, improve the language support. Make the existing stuff more modern, and make the modern stuff more like Notes. Make it better by integrating modern technologies with the core rather than stacking unrelated things on top.  Had IBM continued to improve in these ways, we would not have lost 80% of our footprint.

New Comment