Re: chunked requires?

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> 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
> 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
>
> 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> 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> 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> 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/ 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
> >>> > > _______________________________________________
> >>> > > 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
> >>>
> >>> --
> >>>
> >>> 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
> >
> > _______________________________________________
> > 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

--
Alex Russell
alex@xxxxxxxxxxx     A99F 8785 F491 D5FD 04D7 ACD9 4158 FFDF 2894 6876
alex@xxxxxxxxxxxxxxx BE03 E88D EABB 2116 CC49 8259 CF78 E242 59C3 9723


_______________________________________________
dojo-contributors mailing list
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