Re: Re: chunked requires?

Guys, this sounds great, but aren't you worried about browser caching 
problems?  (Like if you have a 100 page website and each page has an 
on-the-fly customized build, then you have to download 100 different 
customized builds, not to mention issues w/the browser's cache 
overflowing.)  Hopefully I'm wrong and that won't be a big issue.

Eugene Lazutkin wrote:
> 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
>
> _______________________________________________
> dojo-contributors mailing list
> dojo-contributors@xxxxxxxxxxxxxxx
> http://dojotoolkit.org/mailman/listinfo/dojo-contributors