[dojo-contributors] "core dojo", packaging, and the build system
jkuhnert at gmail.com
Wed Apr 5 16:38:12 EDT 2006
In regard to the globally available js package server, I still wish this
were possible. It seems the only barrier is trying to ask 1 entity to host
this, which just isn't feasible.
I wish I knew more tcp/ip routing to make any thoughts I have substantial
but I thought that you can sort of round robin stagger a DNS name to a
number of different physical hosts....If this were possible, and we could
somehow guarantee only a certain amount of traffic going to each particular
entity it might be easier to get more companies/people to volunteer
But, like I said. I don't know enough about networking on this kind of scale
to know if it's feasible.
On 4/5/06, James Burke <jburke at dojotoolkit.org> wrote:
> On 4/5/06, Tom Trenka <ttrenka at gmail.com> wrote:
> > > > 1.) do we want to make builds that include things structured
> > > > like this?
> > >
> > > I am very much in favour of this. When I start on a project the
> > > first stage is usually rapid prototyping and Dojo very much gets in
> > > the way of my process. I'd like to be able to include the Dojo bits
> > > that I need and get on with the task at hand, at the moment Dojo
> > > demands my attention, the package system stands in my way.
> > >
> > > Now I imagine this is a different scenario for widget authors, where
> > > I guess the package system can start to become a blessing as a myriad
> > > of files are required, or such is my impression.
> > I am also very much in favor of this. It would help to counter-act the
> > perception of bloat as well...it's also at this point (I think) that
> > simplified, standard builds such as a build with the base widget system
> > come in very, very handy.
> It seems like for rapid prototyping, if we did have a globally
> available distribution of dojo on a site than anyone can use (since we
> can allow for cross-site includes and preserve the dependency graph),
> that would be the best approach.
> All you would have to do is do a script src include for
> http://public.server.com/dojo/dojo.js, then just start using
> dojo.require() in your code, and you are good to go.
> In this scenario, dojo.js is basically the dependency loader that
> knows how to deal with dependencies in a package.
> I'm not in favor of having raw script src includes for the dojo
> packages, since this puts the burden on the developer to understand
> the dependency graph. Yes, ideally we should have our packages very
> loosely coupled, but in reality some packages will depend on others,
> and we could avoid support emails by taking care of dependencies for
> the user.
> I think this would really give the perception of lightness for dojo:
> "all I do is include this dojo.js and I just start writing code.
> Nothing for me to install on my server!".
> > > > 2.) if so, what would the broad "rollup" files be, and what
> > > > would they include?
> > >
> > > So I think a list of end points would need to be defined, such as;
> > > event, io, dnd, date, html (css, dom)... ad nauseam, and then the
> > > bare minimum for supporting these modules would comprise the base
> > > dojo.js, presumably bootstrap and some of lang at least.
> > >
> > > I also like the idea of spawning the dependancy system into it's own
> > > file, if this is feasible. This would then allow us to provide a
> > > dependancy system which can be picked up by other projects which I
> > > count as a win.
> > Paul's been reading my mind from across the ocean! :) I'd count the
> > dependency system for other projects as a win beyond count; I can't
> think of
> > anything (other than the kickass modular system that would be newer
> > that would be better for the community as a whole.
> I'm advocating that dojo.js would include the dependency loading code,
> since that allows access to all other packages (as long as we have
> cross-domain loading from a globally accessible installation or set of
> globally accessible installations).
> > > > 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?
> > >
> > > I guess the blessing I see is that this the only road block is that
> > > we clean up dependancies to make libraries stand alone, the package
> > > system is one and the same. If the package API is included these
> > > files will continue to have dojo.require and dojo.provide signatures
> > > and so everything will Just Work.
> > Paul, you frighten me. You have some sort of machine there in the UK
> > in the XMen movie or something???
> > trt
> To me, dojo's benefits are (in no particular order):
> 1) The dependency tracking and loading system.
> 2) The widget parsing system.
> 3) Smart contributors making high quality packages, and taking care of
> the nasty cross browser stuff.
> The dependency tracking is a really nice feature, and I favor
> encouraging the use of the dependency code, in particular to new
> users. Using a globally accessible dojo installation makes using dojo
> a no-brainer for new users. Then it is just figuring out package APIs
> -- getting to coding.
> Since the dojo.require() approach allows for a layer of indirection as
> to where files are loaded, users could "upgrade" performance by
> choosing one of the dojo.js files that in addition to the dependency
> loading code inlined some packages. This would then be as simple as
> changing the path to the dojo.js script src attribute.
> dojo-contributors mailing list
> dojo-contributors at dojotoolkit.org
Tacos/Tapestry, team member/developer
Open source based consulting work centered around
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the dojo-contributors