[dojo-contributors] common cometd.js for dojo & jquery

Dustin Machi dmachi at dojotoolkit.org
Wed May 6 08:24:57 EDT 2009

Comments inline.

>> * will people ever use the dojox.cometd client without using Dojo?
> Depends on what you mean by "using dojo".
> dojox.cometd uses dojo's io and json features.
> But some users will only use dojox.cometd and directly use
> other parts of dojo.

Does this imply that the new implementation will have an abstraction  
layer and not use things like Dojo's I/O system and other functions/ 
utilities it currently uses from Dojo?  If this is the case it seems  
like this move will penalize Dojo by having extra code to implement  
this abstraction layer.

While I am not particularly concerned with what namespace the cometd  
client ends up in (comments by Greg and Dylan about the path  
notwithstanding), I do think it is important to still be able to pull  
this code into a build as with the rest of the Dojo code or it again  
seems like we're penalizing Dojo because the other libs don't support  
advanced features such as packaging and building (while Dojo was here  
first :P).  IMO if we end up with something that is abstracted and  
larger, and prevents normal dojo.require()/builds, someone will end up  
re-implementing it or will use the old client...and of course that  
probably doesn't help any of us.

>> * how will the Dojo download and build process evolve to handle other
>> code that lives at third-party locations?
> The BIG questions :)

Of course having this available in dojox.cometd as it is today is  
probably the simplest solution from a end user perspective.  However,  
for something advanced like this, I don't personally care whether it  
ends up in one of the three primary Dojo namespaces.  I do think  
however, if it isn't it should be able to be downloaded into another  
appropriate namespace (cometd, cometd.client, or org.cometd..though  
this last one always seems backwards in javascript to me) and then  
pulled in using normal dojo.require() and be usable within a build.

>> So, some of these questions are easy to answer, but others have no  
>> clear
>> right answer in my opinion, unfortunately.
>> What matters most to me is, what's easiest for end users, and then,  
>> what
>> is easiest for committers to maintain?  So, at first I thought the
>> following:
>> * org.cometd (or whatever we call it, and perhaps dojox.cometd)  
>> should
>> be an svn:externals from within the Dojo repo to the cometD repo
>> * we should keep the provide/require syntax as simple and  
>> consistent as
>> possible for everything needed for Dojo users, so if the following
>> works, do it (if not, find something equally easy):
>> if(typeof dojo != "undefined"){
>> 	dojo.provide("org.cometd");
>> }
> I'm inclined to agree that this is the simplest way to proceed for  
> this case.

One slight alternative to this might be to create a  
dojo.requireJS(moduleName, pathToJS)  which would load in a non-dojo  
js file and wrap it with the provide defined in moduleName.  This  
would leave all the existing functionality alone, and provide a  
standardized way of pulling in other non-dojo-provide js.  The nls  
system does something similar today.

This of course would require a handler for this in the buildscripts to  
work with a build.  I'd think this could be done with xdomain as well,  
but James would have to comment on that.


More information about the dojo-contributors mailing list