[dojo-contributors] "core dojo", packaging, and the build system

Tom Trenka ttrenka at gmail.com
Wed Apr 5 16:52:30 EDT 2006


This topic was floated once before when AOL announced the "iamalpha"
concept; the main issue here is hosting the actual code, which the Dojo
Foundation can't really afford to do (IIRC).

There's a blog post about it somewhere, let me see if I can find it...
http://blog.dojotoolkit.org/2006/01/30/dojo-iamalpha-and-cdns

trt

On 4/5/06, Jesse Kuhnert <jkuhnert at gmail.com> wrote:
>
> 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
> bandwidth/server resources.
>
> 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 will
> > > 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
> > Dojo)
> > > 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
> > like
> > > 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.
> >
> > James
> > _______________________________________________
> > dojo-contributors mailing list
> > dojo-contributors at dojotoolkit.org
> > http://dojotoolkit.org/mailman/listinfo/dojo-contributors
> >
>
>
>
> --
> Jesse Kuhnert
> Tacos/Tapestry, team member/developer
>
> Open source based consulting work centered around
> dojo/tapestry/tacos/hivemind.  http://opennotion.com
>
> _______________________________________________
> dojo-contributors mailing list
> dojo-contributors at dojotoolkit.org
> http://dojotoolkit.org/mailman/listinfo/dojo-contributors
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.dojotoolkit.org/pipermail/dojo-contributors/attachments/20060405/36fce72f/attachment.htm 


More information about the dojo-contributors mailing list