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. <br><br>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.
<br><br>But, like I said. I don't know enough about networking on this kind of scale to know if it's feasible. <br><br><div><span class="gmail_quote">On 4/5/06, <b class="gmail_sendername">James Burke</b> <<a href="mailto:firstname.lastname@example.org">
email@example.com</a>> wrote:</span><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">On 4/5/06, Tom Trenka <<a href="mailto:firstname.lastname@example.org">
email@example.com</a>> wrote:<br>><br>><br>> > > 1.) do we want to make builds that include things structured<br>> > > like this?<br>> ><br>> > I am very much in favour of this. When I start on a project the
<br>> > first stage is usually rapid prototyping and Dojo very much gets in<br>> > the way of my process. I'd like to be able to include the Dojo bits<br>> > that I need and get on with the task at hand, at the moment Dojo
<br>> > demands my attention, the package system stands in my way.<br>> ><br>> > Now I imagine this is a different scenario for widget authors, where<br>> > I guess the package system can start to become a blessing as a myriad
<br>> > of files are required, or such is my impression.<br>><br>><br>> I am also very much in favor of this. It would help to counter-act the<br>> perception of bloat as well...it's also at this point (I think) that
<br>> simplified, standard builds such as a build with the base widget system will<br>> come in very, very handy.<br><br>It seems like for rapid prototyping, if we did have a globally<br>available distribution of dojo on a site than anyone can use (since we
<br>can allow for cross-site includes and preserve the dependency graph),<br>that would be the best approach.<br><br>All you would have to do is do a script src include for<br><a href="http://public.server.com/dojo/dojo.js">
http://public.server.com/dojo/dojo.js</a>, then just start using<br>dojo.require() in your code, and you are good to go.<br><br>In this scenario, dojo.js is basically the dependency loader that<br>knows how to deal with dependencies in a package.
<br><br>I'm not in favor of having raw script src includes for the dojo<br>packages, since this puts the burden on the developer to understand<br>the dependency graph. Yes, ideally we should have our packages very<br>loosely coupled, but in reality some packages will depend on others,
<br>and we could avoid support emails by taking care of dependencies for<br>the user.<br><br>I think this would really give the perception of lightness for dojo:<br>"all I do is include this dojo.js and I just start writing code.
<br>Nothing for me to install on my server!".<br><br>><br>> > > 2.) if so, what would the broad "rollup" files be, and what<br>> > > would they include?<br>> ><br>> > So I think a list of end points would need to be defined, such as;
<br>> > event, io, dnd, date, html (css, dom)... ad nauseam, and then the<br>> > bare minimum for supporting these modules would comprise the base<br>> > dojo.js, presumably bootstrap and some of lang at least.
<br>> ><br>> > I also like the idea of spawning the dependancy system into it's own<br>> > file, if this is feasible. This would then allow us to provide a<br>> > dependancy system which can be picked up by other projects which I
<br>> > count as a win.<br>><br>><br>> Paul's been reading my mind from across the ocean! :) I'd count the<br>> dependency system for other projects as a win beyond count; I can't think of<br>> anything (other than the kickass modular system that would be newer Dojo)
<br>> that would be better for the community as a whole.<br><br>I'm advocating that dojo.js would include the dependency loading code,<br>since that allows access to all other packages (as long as we have<br>cross-domain loading from a globally accessible installation or set of
<br>globally accessible installations).<br><br>> > > 3.) how would we communicate to users how to use these build<br>> > > files in conjunction with the package system? or would it be a "non-<br>
> > > package system" build?<br>> ><br>> > I guess the blessing I see is that this the only road block is that<br>> > we clean up dependancies to make libraries stand alone, the package<br>
> > system is one and the same. If the package API is included these<br>> > files will continue to have dojo.require and dojo.provide signatures<br>> > and so everything will Just Work.<br>><br>><br>
> Paul, you frighten me. You have some sort of machine there in the UK like<br>> in the XMen movie or something???<br>><br>> trt<br><br>To me, dojo's benefits are (in no particular order):<br>1) The dependency tracking and loading system.
<br>2) The widget parsing system.<br>3) Smart contributors making high quality packages, and taking care of<br>the nasty cross browser stuff.<br><br>The dependency tracking is a really nice feature, and I favor<br>encouraging the use of the dependency code, in particular to new
<br>users. Using a globally accessible dojo installation makes using dojo<br>a no-brainer for new users. Then it is just figuring out package APIs<br>-- getting to coding.<br><br>Since the dojo.require() approach allows for a layer of indirection as
<br>to where files are loaded, users could "upgrade" performance by<br>choosing one of the dojo.js files that in addition to the dependency<br>loading code inlined some packages. This would then be as simple as<br>
changing the path to the dojo.js script src attribute.<br><br>James<br>_______________________________________________<br>dojo-contributors mailing list<br><a href="mailto:firstname.lastname@example.org">email@example.com
</a><br><a href="http://dojotoolkit.org/mailman/listinfo/dojo-contributors">http://dojotoolkit.org/mailman/listinfo/dojo-contributors</a><br></blockquote></div><br><br clear="all"><br>-- <br>Jesse Kuhnert<br>Tacos/Tapestry, team member/developer
<br><br>Open source based consulting work centered around dojo/tapestry/tacos/hivemind. <a href="http://opennotion.com">http://opennotion.com</a>