CometD 2.5.0-beta1 Released
14 views
Skip to first unread message
Simone Bordet
May 21, 2012, 1:12:19 PM5/21/12
to cometd-users, cometd-dev
Hi all,
CometD 2.5.0-beta1 has been released.
Release Notes: http://bugs.cometd.org/secure/ReleaseNote.jspa?projectId=10000&version=10473
The most important feature of this release is the support, for the JavaScript client library, for script loaders that use AMD (asynchronous module definition).
For those that live under a stone, AMD is the de facto standard for resolving module dependencies of JavaScript files and libraries (https://github.com/amdjs/amdjs-api/wiki/AMD) and allowing script loaders to leverage those dependencies to optimize script loading times.
Dojo 1.7 has already fully embraced the AMD way, jQuery did not natively embrace it but supports it, and I guess other JavaScript toolkits are on their way to support it if not already.
------
What does it change for existing CometD applications that want to update from CometD 2.4.x or earlier to CometD 2.5.x ?
Very little.
Existing Dojo-based CometD webapps can be easily ported to CometD 2.5.x by adding one line in their JavaScript:
Dojo + CometD 2.4.x or earlier:
<html>
<script src="dojo/dojo.js"></script>
<script>
dojo.require("dojox.cometd");
...
</script>
...
</html>
Dojo + CometD 2.5.x or greater:
<html>
<script src="dojo/dojo.js"></script>
<script>
dojo.registerModulePath("org", "../org");
dojo.require("dojox.cometd");
...
</script>
...
</html>
The only difference is the "dojo.registerModulePath("org", "../org");" call that needs to be added.
This is needed because CometD 2.4.x hardcoded the path of the common CometD JS implementation (to be "../org", relative to the dojo directory), while now application developers may choose to put it under any path they want, provided that they call registerModulePath() with the path they want to use.
No changes are required for jQuery-based CometD applications.
------
For *new* Dojo-based applications, we recommend to use the AMD style, and to make use of the "tlmSiblingsOfDojo: true" configuration attribute, or to use a configuration object specifying the "packages" field in the call to require().
Any CometD application based on RequireJS (see http://requirejs.org) can simply use the RequireJS/AMD style without problems.
------
CometD 2.5.x ships updated demos that you can use as examples for your needs:
* Dojo 1.7 AMD-style demo: the Reload demo, the Chat demo
* Dojo 1.7 non-AMD demo: the Echo demo, the TimeSync demo
* jQuery + RequireJS demo: the Reload demo
* jQuery non-AMD demo: the Chat demo.
The style for Dojo 1.7 AMD and jQuery+RequireJS is essentially identical, apart differences in configuration for the require() call.
------
Overall, transitioning to CometD 2.5.0 is, in the worst case, a one-line change, but will be good to update for the future of your web applications since AMD seems to have won the battle.
I encourage to try out CometD 2.5.0, report any problem, and feedback the CometD lists about how's CometD 2.5.0 doing for you.
Enjoy !
Simon
--
http://cometd.org
http://intalio.com
http://bordet.blogspot.com
----
Finally, no matter how good the architecture and design are,
to deliver bug-free software with optimal performance and reliability,
the implementation technique must be flawless. Victoria Livschitz
CometD 2.5.0-beta1 has been released.
Release Notes: http://bugs.cometd.org/secure/ReleaseNote.jspa?projectId=10000&version=10473
The most important feature of this release is the support, for the JavaScript client library, for script loaders that use AMD (asynchronous module definition).
For those that live under a stone, AMD is the de facto standard for resolving module dependencies of JavaScript files and libraries (https://github.com/amdjs/amdjs-api/wiki/AMD) and allowing script loaders to leverage those dependencies to optimize script loading times.
Dojo 1.7 has already fully embraced the AMD way, jQuery did not natively embrace it but supports it, and I guess other JavaScript toolkits are on their way to support it if not already.
------
What does it change for existing CometD applications that want to update from CometD 2.4.x or earlier to CometD 2.5.x ?
Very little.
Existing Dojo-based CometD webapps can be easily ported to CometD 2.5.x by adding one line in their JavaScript:
Dojo + CometD 2.4.x or earlier:
<html>
<script src="dojo/dojo.js"></script>
<script>
dojo.require("dojox.cometd");
...
</script>
...
</html>
Dojo + CometD 2.5.x or greater:
<html>
<script src="dojo/dojo.js"></script>
<script>
dojo.registerModulePath("org", "../org");
dojo.require("dojox.cometd");
...
</script>
...
</html>
The only difference is the "dojo.registerModulePath("org", "../org");" call that needs to be added.
This is needed because CometD 2.4.x hardcoded the path of the common CometD JS implementation (to be "../org", relative to the dojo directory), while now application developers may choose to put it under any path they want, provided that they call registerModulePath() with the path they want to use.
No changes are required for jQuery-based CometD applications.
------
For *new* Dojo-based applications, we recommend to use the AMD style, and to make use of the "tlmSiblingsOfDojo: true" configuration attribute, or to use a configuration object specifying the "packages" field in the call to require().
Any CometD application based on RequireJS (see http://requirejs.org) can simply use the RequireJS/AMD style without problems.
------
CometD 2.5.x ships updated demos that you can use as examples for your needs:
* Dojo 1.7 AMD-style demo: the Reload demo, the Chat demo
* Dojo 1.7 non-AMD demo: the Echo demo, the TimeSync demo
* jQuery + RequireJS demo: the Reload demo
* jQuery non-AMD demo: the Chat demo.
The style for Dojo 1.7 AMD and jQuery+RequireJS is essentially identical, apart differences in configuration for the require() call.
------
Overall, transitioning to CometD 2.5.0 is, in the worst case, a one-line change, but will be good to update for the future of your web applications since AMD seems to have won the battle.
I encourage to try out CometD 2.5.0, report any problem, and feedback the CometD lists about how's CometD 2.5.0 doing for you.
Enjoy !
Simon
--
http://cometd.org
http://intalio.com
http://bordet.blogspot.com
----
Finally, no matter how good the architecture and design are,
to deliver bug-free software with optimal performance and reliability,
the implementation technique must be flawless. Victoria Livschitz
Maurice McCabe
May 21, 2012, 6:50:22 PM5/21/12
to comet...@googlegroups.com, cometd-users
Simon, nice job. This has allowed me to turn on AMD in async mode (when using cometd) and has dramatically increased my app load time.
Thanks,
Maurice
Thanks,
Maurice
Reply all
Reply to author
Forward
0 new messages