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

Greg Wilkins gregw at mortbay.com
Wed May 6 06:34:59 EDT 2009


Dylan Schiemann wrote:
> 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.

Historically Alex and I have done most of the work on dojox.cometd
and we both have commit.

But this is a change of the core implementation to a common version
that was written by simone, who is only a cometd committer.

So I'd expect that significant work will be done by non dojo committers.
But they will mostly be dojo foundation committers.

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

Yes.  It is already used with other servers (even if they are mostly
derived from the cometd code base).

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

> * 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?

Yes.

but cross mounts can be ugly. It might work ok for for a one off, but
is probably not a good general solution.

> * what choice will be easiest for end users?

End users just want to say dojo.require("dojox.cometd") and have it work.

So I think this is really an issue of ease of development and release procedures

> * what will encourage the most adoption?

as above.

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

Anything that avoids cut and paste or patching will be simplest.
But if it breaks dojo's loader, then that will just cause other
issues.

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

The BIG questions :)

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


> 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

+1.   Avoiding the need to maintain module loading locations is essential
if the simplicity of use is to be maintained.

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

ok

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

Hmmm  While I don't like svn:externals, I like them more that cut and past!

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

That breaks the current run from source development model of dojo.

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

the cross mounts should avoid the copy.  But I just don't think it is
a good general solution for other dojox project... but maybe cometd is
unique?

cheers


> Regards,
> -Dylan
> 
> 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
> _______________________________________________
> 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