Re: chunked requires?

If API for this kind of stuff is documented properly, and Dojo can be
hinted to use a server-side help, we can create a set of back-ends for
that. E.g., I would definitely like to write it for Django.

Thanks,

Eugene

Jesse Kuhnert wrote:
> Yeah guys that does look very promising. Sorry for not responding sooner.
> 
> I wouldn't worry about the dirty code problems, if the fundamentals are
> workable we can always fix that stuff. I'm fairly busy this week but if
> I can manage to create a wiki page outlining branching/etc stuff
> hopefully we should have a normal alpha/whatever type of trunk to dump
> these kinds of things into again soon.
> 
> On 10/29/06, *Alex Russell* <alex@xxxxxxxxxxxxxxx
> <mailto:alex@xxxxxxxxxxxxxxx>> wrote:
> 
>     That's REALLY REALLY cool.
> 
>     On Saturday 28 October 2006 8:27 pm, Timothy Williamson wrote:
>     > We've got some code that builds the require chain info and a servlet
>     > that fires back mini-builds on demand.  We just pushed it out in our
>     > release last night.  For an example, go to:
>     >       http://testapp.ning.com/xn/loader?
>     > require=dojo.widget.*,dojo.html,ning.Bar&prefixes=dojo:src,ning:../
>     > ning&have=ning.loader,dojo.lang,dojo.io.IO <http://dojo.io.IO>
>     > For debugging purposes, you can also tack on uncompressed=true
>     > On Ning, we use this both to make efficient bulk requires and to do
>     > async requires so that background stuff doesn't lock up the browser.
>     > You can see the simple JS interface for this at:
>     >       http://testapp.ning.com/xn/static/js/ning/loader.js
>     <http://testapp.ning.com/xn/static/js/ning/loader.js>
>     >
>     > Using a bit of trickier, you can even get it to build 0.4 packages by
>     > uploading the source and mucking with the package prefix, e.g.:
>     >       http://testapp.ning.com/xn/loader?
>     > require=dojo.widget.*&prefixes=dojo:../../../../dojo/trunk/src
>     >
>     > If you're interested, I can probably get the go ahead to pass along
>     > the (somewhat embarrassingly ugly) code.  We have to deal with dojo
>     > 0.3.1, but if you wanted to target just 0.4, then a lot of the Java
>     > code can be simplified, thanks to the great work you guys have been
>     > doing to clean up the provide/require stuff.
>     >
>     > --Tim
>     >
>     > > I'm working on building an XML/JSON file that shows the requires
>     > > chain. There's no reason we couldn't keep that data up to date in
>     > > the repository, and write a Dojo module that passed the client's
>     > > already loaded files, and said what file it wants. You can use the
>     > > saved require chain to find what needs to be concatenated together,
>     > > and pipe it back.
>     > >
>     > > -Neil
>     > >
>     > > On Oct 22, 2006, at 11:16 PM, Adam L. Peller wrote:
>     > >> Sticking to these principles, nothing done so far in i18n
>     > >> *requires* a
>     > >> build.  However, for performance reasons, it's a good idea.
>     > >> Exactly how we choose add / factor the localized resources, like
>     > >> how we factor
>     > >> the JS code itself in Dojo, is a matter of tradeoffs (namely # of
>     > >> hits) if you're not doing a build.
>     > >>
>     > >> -Adam
>     > >>
>     > >> On 10/22/06, Jesse Kuhnert <jkuhnert@xxxxxxxxx
>     <mailto:jkuhnert@xxxxxxxxx>> wrote:
>     > >>> No, unfortunately all of my users are used to semi transparent
>     > >>> localization.
>     > >>> At least as much as a combination of the jdk & localized
>     > >>> properties files
>     > >>> can provide. I don't think asking them to do a "build" of
>     > >>> anything is going
>     > >>> to be an acceptable solution for me to give them.
>     > >>>
>     > >>> Certainly they should/hopefully will eventually build their own
>     > >>> dojo build
>     > >>> for each specific app - but it has to still be "intuitive-ish"
>     > >>> without doing
>     > >>> it. Oh well, that's the price I pay for taking such a bold step
>     > >>> with it. I
>     > >>> don't want it to be a dojo specific concern if it doesn't fit the
>     > >>> ideal
>     > >>> design of the system on it's own. Know what I mean?
>     > >>>
>     > >>> Also, we may want to stop and ponder what it means if we start to
>     > >>> move in
>     > >>> the direction of it becoming unheard of to do X or Y in dojo
>     > >>> without using a
>     > >>> tool. It should stand well on it's own. imho at least..
>     > >>>
>     > >>> On 10/22/06, Adam L. Peller <adam@xxxxxxxxxx
>     <mailto:adam@xxxxxxxxxx>> wrote:
>     > >>> > Isn't this what the build system is for? :-)
>     > >>> >
>     > >>> > Seriously, though, if you think you could accomplish some sort
>     > >>> > of batching from the client, that's an interesting proposal.
>     > >>> > Lazy-loading might also be accomplished with smaller "chunked"
>     > >>>
>     > >>> builds.
>     > >>>
>     > >>> > But I'm not sure I understand why a page like this would not
>     > >>>
>     > >>> have the
>     > >>>
>     > >>> > widgets and their dependencies in a pre-built dojo.js.
>     > >>> >
>     > >>> > The localization code does add several new hits unfortunately,
>     > >>>
>     > >>> and as
>     > >>>
>     > >>> > we localize more widgets, there will likely be even more hits.
>     > >>> > Localized resources might end up factored out into smaller
>     > >>>
>     > >>> files to
>     > >>>
>     > >>> > minimize network traffic, but this too assumes that people are
>     > >>>
>     > >>> doing
>     > >>>
>     > >>> > builds for their production.  If this is not a valid
>     > >>>
>     > >>> assumption, we
>     > >>>
>     > >>> > should discuss.
>     > >>> >
>     > >>> >
>     > >>> > -Adam
>     > >>> >
>     > >>> > On 10/22/06, Jesse Kuhnert <jkuhnert@xxxxxxxxx
>     <mailto:jkuhnert@xxxxxxxxx>> wrote:
>     > >>> > > I haven't actually verified anything but with nothing else
>     > >>>
>     > >>> discernible
>     > >>> to go
>     > >>>
>     > >>> > > on I'm going to blame the somewhat sluggish loading of some
>     > >>>
>     > >>> of the dojo
>     > >>>
>     > >>> > > stuff I've been working with on the # of require calls made.
>     > >>>
>     > >>> (Compare
>     > >>> the
>     > >>>
>     > >>> > > load of http://opencomponentry.com:8080/tacos/ to
>     > >>> > > http://opencomponentry.com:8080/timetracker/
>     <http://opencomponentry.com:8080/timetracker/> and you
>     > >>>
>     > >>> will
>     > >>>
>     > >>> > > see what I mean. In theory the timetracker url should be
>     > >>>
>     > >>> faster as it is
>     > >>>
>     > >>> > > using the latest code - as of yesterday I believe - whereas
>     > >>>
>     > >>> the tacos
>     > >>> url is
>     > >>>
>     > >>> > > on 0.3.1 )
>     > >>> > >
>     > >>> > > I'm planning on hacking together some sort of multi response
>     > >>>
>     > >>> require
>     > >>>
>     > >>> > > protocol locally, but as I'm assuming this might prove
>     > >>>
>     > >>> beneficial to
>     > >>> more
>     > >>>
>     > >>> > > people I thought I'd throw it out there "just in case". For
>     > >>>
>     > >>> my specific
>     > >>>
>     > >>> > > needs I pretty much have complete control over any semantics
>     > >>>
>     > >>> involved in
>     > >>> the
>     > >>>
>     > >>> > > protocol as assets are handled by a special service for this
>     > >>>
>     > >>> task
>     > >>> already.
>     > >>>
>     > >>> > > (it does all kinds of crazy crap already to make all browsers
>     > >>>
>     > >>> happy with
>     > >>>
>     > >>> > > various "quircks" here and there...)
>     > >>> > >
>     > >>> > > The basic idea is of course to replace the 10(or so) separate
>     > >>>
>     > >>> require()
>     > >>> get
>     > >>>
>     > >>> > > requests with one single request that returns all 10 as a
>     > >>> > > single
>     > >>>
>     > >>> response.
>     > >>>
>     > >>> > > (in the right order).
>     > >>> > >
>     > >>> > > Anyone else care about this or should I go it alone? (or are
>     > >>>
>     > >>> there any
>     > >>> other
>     > >>>
>     > >>> > > ideas other than brute force trying to create as large a
>     > >>>
>     > >>> dojo.js file as
>     > >>>
>     > >>> > > possible? )
>     > >>> > >
>     > >>> > > --
>     > >>> > > Jesse Kuhnert
>     > >>> > > Tapestry/Dojo/(and a dash of TestNG), team member/developer
>     > >>> > >
>     > >>> > > Open source based consulting work centered around
>     > >>> > > dojo/tapestry/tacos/hivemind.
>     http://blog.opencomponentry.com <http://blog.opencomponentry.com>
>     > >>> > > _______________________________________________
>     > >>> > > dojo-contributors mailing list
>     > >>> > > dojo-contributors@xxxxxxxxxxxxxxx
>     <mailto:dojo-contributors@xxxxxxxxxxxxxxx>
>     > >>>
>     > >>> http://dojotoolkit.org/mailman/listinfo/dojo-contributors
>     > >>>
>     > >>> > _______________________________________________
>     > >>> > dojo-contributors mailing list
>     > >>> > dojo-contributors@xxxxxxxxxxxxxxx
>     <mailto:dojo-contributors@xxxxxxxxxxxxxxx>
>     > >>> > http://dojotoolkit.org/mailman/listinfo/dojo-contributors
>     > >>>
>     > >>> --
>     > >>>
>     > >>> Jesse Kuhnert
>     > >>> Tapestry/Dojo/(and a dash of TestNG), team member/developer
>     > >>>
>     > >>> Open source based consulting work centered around
>     > >>> dojo/tapestry/tacos/hivemind. http://blog.opencomponentry.com
>     > >>> _______________________________________________
>     > >>> dojo-contributors mailing list
>     > >>> dojo-contributors@xxxxxxxxxxxxxxx
>     <mailto:dojo-contributors@xxxxxxxxxxxxxxx>
>     > >>> http://dojotoolkit.org/mailman/listinfo/dojo-contributors
>     > >>
>     > >> _______________________________________________
>     > >> dojo-contributors mailing list
>     > >> dojo-contributors@xxxxxxxxxxxxxxx
>     <mailto:dojo-contributors@xxxxxxxxxxxxxxx>
>     > >> http://dojotoolkit.org/mailman/listinfo/dojo-contributors
>     > >
>     > > _______________________________________________
>     > > dojo-contributors mailing list
>     > > dojo-contributors@xxxxxxxxxxxxxxx
>     <mailto:dojo-contributors@xxxxxxxxxxxxxxx>
>     > > http://dojotoolkit.org/mailman/listinfo/dojo-contributors
>     >
>     > _______________________________________________
>     > dojo-contributors mailing list
>     > dojo-contributors@xxxxxxxxxxxxxxx
>     <mailto:dojo-contributors@xxxxxxxxxxxxxxx>
>     > http://dojotoolkit.org/mailman/listinfo/dojo-contributors
>     <http://dojotoolkit.org/mailman/listinfo/dojo-contributors>
> 
>     --
>     Alex Russell
>     alex@xxxxxxxxxxx <mailto:alex@xxxxxxxxxxx>     A99F 8785 F491 D5FD
>     04D7 ACD9 4158 FFDF 2894 6876
>     alex@xxxxxxxxxxxxxxx <mailto:alex@xxxxxxxxxxxxxxx> BE03 E88D EABB
>     2116 CC49 8259 CF78 E242 59C3 9723
> 
> 
>     _______________________________________________
>     dojo-contributors mailing list
>     dojo-contributors@xxxxxxxxxxxxxxx
>     <mailto:dojo-contributors@xxxxxxxxxxxxxxx>
>     http://dojotoolkit.org/mailman/listinfo/dojo-contributors
> 
> 
> 
> 
> 
> 
> -- 
> Jesse Kuhnert
> Tapestry/Dojo/(and a dash of TestNG), team member/developer
> 
> Open source based consulting work centered around
> dojo/tapestry/tacos/hivemind. http://blog.opencomponentry.com
> 
> 
> ------------------------------------------------------------------------
> 
> _______________________________________________
> dojo-contributors mailing list
> dojo-contributors@xxxxxxxxxxxxxxx
> http://dojotoolkit.org/mailman/listinfo/dojo-contributors