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

Greg Wilkins gregw at mortbay.com
Sat May 9 03:38:46 EDT 2009

Dustin Machi wrote:
> 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.

The cometd.js class itself is not functional, as it only has stub
methods for json, XHR and binding args to functions.

These stubs have to be provided be each and every implementation,
so both dojo and jquery have to have an "extra layer".  But at runtime,
this is zero cost.

> 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 

I completely agree.

The bottom line is that dojo.require("dojox.cometd") should pull in
everything that is required and should work with custom builds like
any other component.

So the questions I'm asking are really just about what it the
best development setup to achieve this without cut and paste.

> 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.

I don't think there are any compromises being asked of for the dojo
implementation.  In fact, I think the new impl is smaller than
the old.


>>> * 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.
> Dustin
> _______________________________________________
> dojo-contributors mailing list
> dojo-contributors at mail.dojotoolkit.org
> http://mail.dojotoolkit.org/mailman/listinfo/dojo-contributors

More information about the dojo-contributors mailing list