+1 great idea, i think caching has to be handled carefully but there should not be any stoppers.
Michael On Mar 23, 5:15 pm, Nathan Wells <nwwe...@gmail.com> wrote: > Ooo good point... but couldn't you just set caching headers on the > result? I guess I'm not clear on the intricacies of how each browser > would handle this, but you could keep track of whether the app was > modified on the server. If it hasn't been modified, then send 304. > > Or am I missing something? > > On Mar 23, 9:25 am, Ian Bambury <ianbamb...@gmail.com> wrote: > > > How would you determine if the current code had been cached on the client or > > not? > > > Ian > > >http://examples.roughian.com > > > On 23 March 2010 14:41, Nathan Wells <nwwe...@gmail.com> wrote: > > > > Is there a reason you wouldn't want to determine which permutation to > > > send on the server rather than the client? What I'm thinking is that > > > you could eliminate the need for the selector script entirely if you > > > had a smart enough server. You could even auto generate the code using > > > a linker, I would think. > > > > So, is there a reason why you wouldn't want to do it? > > > > -- > > > You received this message because you are subscribed to the Google Groups > > > "Google Web Toolkit" group. > > > To post to this group, send email to google-web-tool...@googlegroups.com. > > > To unsubscribe from this group, send email to > > > google-web-toolkit+unsubscr...@googlegroups.com<google-web-toolkit%2Bunsubs > > > cr...@googlegroups.com> > > > . > > > For more options, visit this group at > > >http://groups.google.com/group/google-web-toolkit?hl=en. -- You received this message because you are subscribed to the Google Groups "Google Web Toolkit" group. To post to this group, send email to google-web-tool...@googlegroups.com. To unsubscribe from this group, send email to google-web-toolkit+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/google-web-toolkit?hl=en.
