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

Dylan Schiemann dylan at dojotoolkit.org
Wed May 6 03:29:00 EDT 2009

A few questions that should help us decide what to do:

* who's going to maintain the dojox.cometd client (Dojo or cometD)?  I
ask, because generally Dojo committers are not cometD committers.

* will people ever use the dojox.cometd client without a cometD project

* will people ever use the dojox.cometd client without using Dojo?

* is it possible to provide an svn:externals reference to the cometD
client in the right place within the Dojo Foundation repo, or vice versa?

* what choice will be easiest for end users?

* what will encourage the most adoption?

* what is easiest for Dojo and cometD committers to maintain?

* how will the Dojo download and build process evolve to handle other
code that lives at third-party locations?

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

* 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"){

However, I'm inclined to say that we should not call it org.cometd for
what is used in Dojo, as the directory structure will be a challenge, so
I would expect that having it be dojox.cometd.org.cometd might be easier
from a directory structure hack, but I'm not sure... either way, the
namespace and directory structure needs to be super simple

* Dojo committers need commit privs to the dojox.cometd client

* A select group of Dojo committers need commit privs to the org.cometd
portion of the client

I hate to say it, but to me it seems like there's no ideal solution, and
we probably need to just maintain two copies of it (one in the dojo repo
and one in the cometd repo) and sync them up periodically.  Perhaps git
or github would be ideal for managing this... I don't know.

Another possibility: our download and build processes would need to be
able to fetch code from external urls based on a package config file.

So, I see no ideal solution, other than to maintain two copies unless an
easy for users solution emerges.


Greg Wilkins wrote:
> Peter E Higgins 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.
> If dojo was always built with maven.... then the approach I would
> take is for dojox.cometd to consume org.comet javascript as a source
> artefact - and auto apply patches to it to wrap the provides and
> dojox.cometd= around it.
> This would work fine and avoid the risk of patches being made to
> dojox version and not feed backstream to the cometd project.
> Perhaps the existing build tools could be modified to support
> this, but it would still break the run-from-source style of
> dojo development.
> I sounds like dojo.require("org.cometd", true);  is the closest
> thing we have, except that as James has said, it will not
> well participate in module loading with onLoad events etc.
> Using that will probably work, but I expect might result in
> a constant stream of user problems from the onload issues that
> James highlights.
> So perhaps putting
> if(typeof dojo != "undefined"){
>     dojo.provide("org.cometd");
> }
> in all the org.cometd source files is the best way to go.
> It does give dojo some preferred status in cometd, but then
> it is a dojo foundation project after all!
> My only concern is that we might still need to faff about
> with module paths, which will somewhat deprecate the
> niceness of just doing a dojo.request("dojox.cometd");
> Maybe if the source directory from org.cometd project was
> svn cross mounted into dojox/cometd/cometd that could
> resolve the module path issue, but it would give us
> a mount that would need to be updated to cometd tags
> every so often?
> cheers
> _______________________________________________
> 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