The CometD Project is happy to announce the availability of CometD 3.1.0.
CometD 3.1.0 builds on top of the CometD 3.0.x series, bringing improvements and new features.
You can find a migration guide at the official CometD documentation site.
What’s new in CometD 3.1.0
CometD 3.1.0 now supports HTTP/2.
HTTP/2 support should be transparent for applications, since the browser on the client-side and the server (such as Jetty) on the server-side will take care of handling HTTP/2 so that nothing changes for applications.
However, CometD applications may now leverage the fact that the application is deployed over HTTP/2 and remove the limit of only one outstanding long poll per client.
This means that CometD applications that are opened in multiple browser tabs and using HTTP/2 can now have each tab performing the long poll, rather than just one tab.
CometD 3.1.0 brings support for messages containing binary data.
Now that JavaScript has evolved and that it supports binary data types, the use case of uploading or downloading files or other binary data could be more common.
CometD 3.1.0 allows applications to specify binary data in messages, and the CometD implementation will take care of converting the binary data into the textual format (using the Z85 encoding) required to send the message, and of converting the textual format back into binary data when the message is received.
Binary data support is available in both the JavaScript and Java CometD libraries.
In the JavaScript library, several changes have been made to support both the CommonJS and AMD module styles.
CometD 3.1.0 is now also deployed to NPM and Bower.
The package name for both NPM and Bower is cometd, please make sure you filter out all the other variants such as cometd-jquery that are not directly managed by the CometD Project.
The CometD JavaScript library has been designed in a way that leverages bindings to JavaScript toolkits such as jQuery or Dojo.
This is because JavaScript toolkits are really good at working around browser quirks/differences/bugs and we did not want to duplicate all those magic workarounds in CometD itself.
In CometD 3.1.0 a new binding is available, for Angular 1. As a JavaScript toolkit, Angular 1 requires tight integration with other libraries that make XMLHttpRequest calls, and the binding architecture of the CometD JavaScript library fits in just nicely.
You can now use CometD from within Angular 1 applications in a way that is very natural for Angular 1 users.
The JavaScript library now supports also vanilla transports. This means that you are not bound to use bindings, but you can write applications without using any framework or toolkit, or using just the bare minimum support given by module loaders such as RequireJS or build-time tools such as Browserify or webpack.
Supporting vanilla transports was possible since recent browsers have finally fixed all the quirks and agreed on the XMLHttpRequest events that a poor JavaScript developer should use to write portable-across-browsers code.
A couple of new Java APIs have been added, detailed in the migration guide.
What’s changed in CometD 3.1.0
In the JavaScript library, browser evolution also brought support for window.sessionStorage, so now the CometD reload extension is using the SessionStorage mechanism rather than using cookies.
You can find the details on the CometD reload extension documentation.
It is now forbidden to invoke handshake() multiple times without disconnecting in-between, so applications need to ensure that the handshake operation is performed only once.
In order to better support CommonJS, NPM and Bower, the location of the JavaScript files has changed.
Applications will probably need to change paths that were referencing the CometD JavaScript files and bindings as detailed in the migration guide.
Adding support for binary data revealed a mistake in the processing of incoming messages. While this has not been fixed in CometD 3.0.x to avoid breaking existing code, it had to be fixed in CometD 3.1.0 to support correctly binary data.
This change affects only applications that have written custom extensions, implementing either BayeuxServer.Extension.send(...) or ServerSession.Extension.send(...). Refer to the migration guide for further details.
CometD 3.1.0 now supports all Jetty versions from the 9.2.x, 9.3.x and 9.4.x series.
While before only the Jetty 9.2.x series was officially supported, now we have decided to support all the above Jetty series to allow CometD users to benefit from bug fixes and performance improvements that come when upgrading Jetty.
Do not mix Jetty versions, however. If you decide to use Jetty 9.3.15, make sure that all the Jetty libraries used in your CometD application reference that Jetty version, and not other Jetty versions.
What’s been removed in CometD 3.1.0
CometD 3.1.0 drops support for Jackson 1.x, since Jackson 2.x is now mainstream.
Server-side parameter allowMultiSessionsNoBrowser has been removed, since sessions not identified by the CometD cookie are not allowed anymore for security reasons.
Conclusions
CometD 3.1.0 is now the mainstream CometD release, and will be the primary focus for development and bug fixes.
CometD 3.0.x enters the maintenance mode, so that only urgent or sponsored fixes will be applied to it, possibly leading to new CometD 3.0.x releases – although these will be rare.
Work on CometD 4.x will start soon, using issue #647 as the basis to review the CometD APIs to be fully non-blocking and investigating the possibility of adding backpressure.
0 Comments