tl;dr Chromium support for Notes (Eclipse) Client would affect backwards compatibility in some edge cases but could bring a host of benefits

As I read another article about the recent IBM announcement (which was for the benefit of existing ICS customers rather than press and analysts), one word struck me as it has on a number of occasions: Sametime. The product is most definitely dated and the focus on Watson Workspace has no doubt overshadowed it, increased at Social Connections by the news about upcoming audio/visual support in Workspace Essentials. On the server-side, the infrastructure moved from Domino to the now less popular Websphere. That brought an added complexity for Domino houses. On the client-side there is the embedded client for Notes, the standalone client and a web client. The web client suffers from being affected by popup blockers and isn’t particularly pretty.

The world has moved on significantly on desktop applications, browser applications and audio/visual options, as shown by Watson Workspace. The initial plan for this was browser and mobile only. The clamour for a desktop application brought one, as an Electron app using HTML, JavaScript and CSS in a Chromium browser. This is a common approach also used by Slack. Whereas ActiveX, Flash and Java plugins have fallen by the wayside during this decade, HTML5 seems to be the way forward for audio/visual content in a browser. This is what I the approach I expect Watson Workspace to use, though that’s just based on the technologies used to build the Watson Workspace front-end and the lack of dependency on backwards compatibility. It makes sense.

Putting the two concepts together made me think: how feasible is it to embed an Electron app – or a Chromium browser – in the Notes Client? It looks like a lot of groundwork has already been done, based on this Eclipse bug (or feature) report. There’s a lot of discussion, so it’s easier to read this blog post about it. But there are working prototype GitHub repositories and a big push for this.

But let’s step back for a moment and look at why this would be a good idea – for more than just Sametime.

First, for Sametime, it would get closer to a single codestream for web, desktop client and embedded client in Notes. That makes modernisation of the client much more achievable. It would also bring a big-impact delivery for Sametime, bigger than I remember in recent years. And a simple codestream should also make support easier, as well as bringing a standard user experience across the platforms. I have no idea if the rich and enbedded clients are different codestreams for different platforms, but if so, this should remove that issue as well. It could also bring benefits to mobile clients too.

I have no doubt that many audio/visual suppliers use equally out-dated delivery options. But I’m sure they’re also looking at more modern approaches like HTML5. And as products like Slack, Watson Workspace and Microsoft Teams add audio/visual, the impetus to suppliers to modernise will increase. Modernising the Sametime client gives a better platform for moving forward.

But beyond Sametime, this also brings bigger benefits to Notes and addresses a significant elephant-in-the-room: XPiNC. XPages in the Notes Client has always been one of those concepts which is great in theory, not so great in practice. I’ve already blogged on performance which shows why I would now avoid XPiNC for anything other than offline NSF access, Offline access to Domino databases has always been a big selling point and still relevant for a lot of customers. Sometimes there isn’t the dependability on connectivity and the amount of data that needs storing means a native mobile app is not an option. XPiNC fits that gap well. Although there might be other options (a Spring Boot app talking through Notes Client for example), the Notes Client makes sense. But XPiNC has a host of quirks as well as being difficult to debug. It also has a reliance on an out-dated browser renderer in the XULRunner, which is now deprecated. That’s even worse news for XPiNC development, especially if an XPages interface is intended for use from both a browser and XPiNC. Embedding a Chromium browser in Eclipse would give a better, more sustainable option for XPiNC. It would also bring into play the idea of an Electron client for local XPages use, providing there is the XPages runtime engine available.

Yes, it would potentially mean effort around some third-party integrations. Extension points would need adding, but extensibility approaches have already been demonstrated with Connections Customizer and customisation of Connections Pink. It would probably be a different technology to build from, but it depends whether the focus for those suppliers is maintenance only.

As the blog post and bug report shows, a lot of work has already been done. It seems feasible. The next steps would be analysis of the effort required for moving from the current technologies to utilising this. There are doubtless impacts I haven’t considered, but the best way to identify those is to open up the discussion. On the surface it seems a tantalising approach that brings a variety of benefits and enables modernisation.

1 thought on “Worth Considering for #Domino2025?”

  1. My knowledge is dated – but so is the product… Most of the plugins in stand alone Sametime are the same as the ones in the embedded. There are slight diffs for authentication etc but the core incl how it embeds itself in Expeditor is the same.

Leave a Comment

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.