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

Nathan Toone toonetown at dojotoolkit.org
Tue May 5 10:16:07 EDT 2009

I think that the value we'd be adding would be the ability to include  
it via the standard "dojo.require" calls - and to be able to include  
it in a build (I'm guessing).


On May 5, 2009, at 8:08 AM, Adam Peller wrote:

> If this stuff is ultimately going to live somewhere else, I don't see
> any need to maintain a dojox home for cometd in the long-term.  People
> should be encouraged to use it from its new home unless we're adding
> some value -- do you see there being anything additional that
> dojox.cometd would offer?  We do have a little bit of a problem since
> dojox.cometd is marked as 'beta', however.
> -Adam
> On Tue, May 5, 2009 at 3:13 AM, Peter E Higgins  
> <dante at dojotoolkit.org> wrote:
>> What is wrong with maintaining is as if it were like sizzle? The real
>> thing needed here is a dojo.provide() call, and perhaps a  
>> dojox.cometd =
>> org.cometd; in the footer. Why can't Dojo "maintain" it's own dojox
>> cometd from an external repo. The cometd and dojo projects are  
>> under the
>> same CLA's no? We could just add the two required lines and leave in
>> DojoX as "the Dojo port", and allow all the other libraries to  
>> include
>> their own packaging in their own versions. Patches could be applied  
>> if
>> the only natural diff was the two lines and we get to keep the  
>> module on
>> the CDN's.
>> Regards,
>> Peter
>> James Burke wrote:
>>> On Mon, May 4, 2009 at 9:34 PM, Greg Wilkins <gregw at mortbay.com>  
>>> wrote:
>>>> James Burke wrote:
>>>>> 1) In org/cometd.js, have a block near the top of the file with  
>>>>> something like:
>>>>> if(typeof dojo != "undefined"){
>>>>>     dojo.provide("org.cometd");
>>>>> }
>>>> while that would work, it's not that extensible.
>>>> We might end up with similar code for jquery, prototype,
>>>> ext.js etc. etc
>>> That is doubtful: very few (none that I know of) have a module  
>>> loader
>>> like Dojo's. YUI has something, but you specify all the dependencies
>>> outside of the actual files. But maybe it is a concern for the  
>>> future.
>>> If you want to avoid the dojo references, as of Dojo 1.4 (the  
>>> current
>>> trunk code in dojo), you can load the module via
>>> dojo.io.script.get({
>>>     url: "path/to/org/cometd.js",
>>>     load: function(){
>>>         //Do something when the file is loaded.
>>>     }
>>> }
>>> Note that only works with the latest dojo.io.script. Any version  
>>> from
>>> 1.3.x or earlier will not work. It also does not tie into the module
>>> loader, so you would have to wrap the code above in a
>>> dojo.addOnLoad(function(){}) block if you want to do the work done
>>> near page load, and any cometd stuff would have to be set up in that
>>> load: callback from dojo.io.script.get().
>>> It also makes it hard to include the module as part of a custom  
>>> build
>>> -- the developer would have to throw in that typeof dojo/ 
>>> dojo.provide
>>> block in order to use it in a custom build.
>>>>> 2) For users of dojox.cometd, instruct them where to download the
>>>>> org/cometd module and to either place the org directory as a  
>>>>> sibling
>>>>> to dojox or configure the path to org/cometd.js via
>>>>> djConfig.modulePaths = { "org.cometd", "path/to/org/cometd" }.
>>>>> dojo.setModulePath() could also be used instead of
>>>>> djConfig.modulePaths (but after dojo is loaded). Notice for the  
>>>>> path
>>>>> to the cometd.js file, in modulePaths, I left off the ".js" part  
>>>>> of
>>>>> the name. The module mapping in Dojo allows you to specify a
>>>>> modulePath for a directory, or in this case, a specific module,  
>>>>> but
>>>>> just leave off the .js extension for a specific module.
>>>> Well here is the other problem... currently cometd-dojox is
>>>> checked into dojox as part of the whole dojo tree and it is
>>>> released with dojo.
>>>> Perhaps it would be better to split this out of dojox
>>>> so that to code resided and was released from org.cometd
>>>> this would mean that it would be excluded from the dojo
>>>> build system and could not be wrapped up into a custom
>>>> built js.
>>>> This is more than a technical question.   It is really
>>>> about if dojox modules will ever have lifecycles of their
>>>> own.
>>> There is a desire to have dojox subprojects on their own release
>>> cycles, but that will take a bit of work to set up by the dojox  
>>> folks.
>>> I think it is perfectly fine for the module to not live in dojox and
>>> be available from another location. It was nice to have the code  
>>> under
>>> the Dojo-approved licenses/CLA process, but looks like the module is
>>> under Apache which has similar rules.
>>> One downside of it not being in dojox means at least right now  
>>> (since
>>> dojox releases are not broken out), dojox modules get up on the
>>> Google/AOL CDNs which make for easy use/distribution.
>>> James
>>> _______________________________________________
>>> dojo-contributors mailing list
>>> dojo-contributors at mail.dojotoolkit.org
>>> http://mail.dojotoolkit.org/mailman/listinfo/dojo-contributors
>> --
>> Peter E Higgins
>> Dojo Project Lead : http://dojotoolkit.org
>> _______________________________________________
>> dojo-contributors mailing list
>> dojo-contributors at mail.dojotoolkit.org
>> http://mail.dojotoolkit.org/mailman/listinfo/dojo-contributors
> _______________________________________________
> dojo-contributors mailing list
> dojo-contributors at mail.dojotoolkit.org
> http://mail.dojotoolkit.org/mailman/listinfo/dojo-contributors

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 2433 bytes
Desc: not available
Url : http://mail.dojotoolkit.org/pipermail/dojo-contributors/attachments/20090505/d69e584c/attachment.p7s 

More information about the dojo-contributors mailing list