[dojo-contributors] "core dojo", packaging, and the build system
jburke at dojotoolkit.org
Wed Apr 5 01:41:46 EDT 2006
I'm using a new hammer, so I may be trying to see a nail in every
problem, but here goes:
I wonder if we could go extremely distributed. The only script src
used directly in a page would be dojo.js which would basically just be
the package loading system. Condense it for the common hostenv, the
All other packages are loaded in a cross domain manner. See:
This means everyone in the world could use one dojo distribution.
Using your own distribution would still be allowed, but the real
benefit is if you use a global distribution. Have a generous corporate
sponsor host the global distribution. ;) And just for paranoia's sake,
it would be good to have a few "global" installations available. There
would be capabilities to load other packages from other domains too
(not just the global dojo installation), just as developers can define
their own widget namespaces now.
Also, break apart the dojo codebase: releases happen on a package
level, not on a global, "0.3" release level. The package loading
system would know how to load the latest version of a package, or load
a specific version of a package. If dojo.require("dojo.foo") was used,
that would grab the latest version. If dojo.require("dojo.foo",
"0.2.2") was used, the 0.2.2 version would be used.
Developers would be encouraged to ask for specific version packages.
Maybe force using a version if "using the latest" seems like it might
generate too many support emails. Dojo could still decide to "bless" a
set of package distributions as a "0.3" release (and dojo.js could
find out what versions of the packages go with "0.3").
There could be "optimized" dojo.js files like today that include a few
different packages, but those would all be available via the global
distribution (developers wouldn't have to worry about figuring out how
to make a custom build). This means there would be a restricted set of
bundled builds (see below for the hardcore performance freaks).
It think in some ways, this is just a distributed component object
model. There are issues with version tracking, but we have that now
anyway. Of course it is trickier with smaller packages doing releases
But versioning/releasing the dojo packages separately could also help
with the code bloat issue: it would encourage looser coupling, and it
would allow doing more granular, rapid releases without having to wait
for the whole dojo codebase to be ready for a new release. Also,
deprecated APIs could be removed quicker in later versions.
So this makes it very easy for developers who want to use dojo to
start using it right away. No thinking about downloading dojo, doing a
custom build, figuring out if they included the right packages, making
sure they deliver dojo correctly with their applications. All they do
is just include dojo.js and have a small djConfig before it saying
what "global" installation they want to use. That would give the
appearance of an extremely light framework.
Once they graduate from this level and care a little more about
performance, they can choose a bundled dojo.js from the global
installation. Also, given that the global installation is on another
domain, they will get a performance boost in MSIE since it won't use
up one of the two connections to their site.
For the truly hardcore that want to eek every piece of performance
all the dependencies and and does a custom build for them, stripping
out any uncalled code.
I know some of this may sound like science fiction (there are a lot of
ifs in the above), but I do think it is attainable, and attainable
soon. But maybe the granular, multiple package version issue isn't
worth the trouble?
On 4/4/06, Alex Russell <alex at dojotoolkit.org> wrote:
> Before 0.2.2, we quietly slipped a feature into the build system to let
> us exclude some set of APIs from a build, even though they may show up
> as requirements.
> In concrete terms, it will let us do something like:
> Where users could include things in their pages like:
> should they want to manually include these modules or do it across
> We now have to figure out:
> 1.) do we want to make builds that include things structured like this?
> 2.) if so, what would the broad "rollup" files be, and what would they
> 3.) how would we communicate to users how to use these build files in
> conjunction with the package system? or would it be a "non-package
> system" build?
> Alex Russell
> alex at jot.com
> alex at dojotoolkit.org BE03 E88D EABB 2116 CC49 8259 CF78 E242 59C3 9723
> dojo-contributors mailing list
> dojo-contributors at dojotoolkit.org
More information about the dojo-contributors