« Ah the web, IJustMadeLove.com | Main| Quick demo video of the Slingcatcher »

Domino team, please teach the Sametime team about backwards compatibility.

Category

One of the things that the eclipse client developers don't seem to take as seriously as the Domino server folks is backwards compatiblity.  We're always finding little things that need tweaking in releases, now in the Sametime 8.5 we just found a big one.  In Sametime 8.5 there is no longer the XULrunner component.  XULrunner was the embedded browser that ran inside the Sametime client.  So any plugin that was developed using that component of Sametime is now broken.

Now here's the challenge, find the release note, technote, infocenter where this is documented, go on I challenge you.

Comments

Gravatar Image1 - c'mon Carl, backward compatibility doesn't apply IBM Java/WAS apps.

Nor does 'in-place upgrade'.


Gravatar Image2 - I get a feeling that QA doesn't apply too Emoticon

Gravatar Image3 - it's still there , but it the SWT version of it. Emoticon

Gravatar Image4 - @3 Anonymous person, if you have a plug-in that had a requirement for the component com.ibm.collaboration.realtime.browser.xulrunner it now gives an error so you can't install.

Gravatar Image5 - I think they (as in eclipse.org) care as well, but they have a difference between API and non API (internal). Only if a class/method is explicitly labeled as API it is guaranteed that nothing will change (or in some rare cases documented). You can use non-API, but at your own risk...

Anyway, the plugin referenced in @4 is not a eclipse one, but an IBM one. I'm not sure what API guarantee they gave in that plugin...

Gravatar Image6 - Took some researching but here is the full explanation.

First, the browser.xulrunner plugin is not publically supported Sametime API (hence no doc!). Sametime has a com.ibm.collaboration.realtime.browser plugin that provides the browser APIs Sametime uses. The xulrunner plugin is the implementation of this API, and Sametime does not depend on it directly. Incidentally there are other ways to avoid depending on a bundle by name (e.g. using import package instead probably might have worked in this case).

The next part is possibly more info than you care for, but it explains the naming history and why the name changed for internal compatibility reasons between the Sametime stand-alone and Notes at the time of Sametime Connect 8.0.2 and Notes 8.5.1. The com.ibm.collaboration.realtime.browser.xulrunner name was changed to com.ibm.collaboration.realtime.browser.dom in the Sametime 8.0.2 stream when that code was included in Notes 851. This is because Notes 8.5.1 had moved to a new version of xulrunner and at the same time, the Sametime 8.0.2 stream needed to maintain support for the original version we shipped with Sametime Connect 8.0.2 standalone. Sametime therefore had two xul plugins in the 8.0.2 stream, one for the standalone Sametime 8.0.2 variant, and one for embedded in Notes 8.5.1.

This conflict is no longer an issue starting in Sametime 8.5 since it can be installed on top of Notes 8.5.1 replacing the Notes embedded version. This should be the case going forward.

So to sum up, the name was only changed to "browser.dom" in the Sametime 8.0.2 to avoid clash with Notes 8.5.1 naming. It has since reverted to "browser.xulrunner".

Post A Comment

:-D:-o:-p:-x:-(:-):-\:angry::cool::cry::emb::grin::huh::laugh::rolleyes:;-)