On Mar 24, 11:42 am, Thomas Broyer t.bro...@gmail.com wrote:
On Mar 24, 5:09 pm, Nathan Wells nwwe...@gmail.com wrote:
You're correct, in more complex environments where a more robust
property provider is necessary, my approach wouldn't do much good. But
then, I'm not talking about
+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
You're correct, in more complex environments where a more robust
property provider is necessary, my approach wouldn't do much good. But
then, I'm not talking about handling those use cases. The goal is to
not make an unnecessary request, and if I have the user agent in the
server on the initial
On Mar 24, 5:09 pm, Nathan Wells nwwe...@gmail.com wrote:
You're correct, in more complex environments where a more robust
property provider is necessary, my approach wouldn't do much good. But
then, I'm not talking about handling those use cases. The goal is to
not make an unnecessary
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
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?
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?
