On 13 feb., 18:44, Timothy Perrett <[email protected]> wrote: > Seems like this conversation is diverging somewhat. > > Can I suggest there are two things in play here, and they address different > problems. > > 1. Stopping the caching of resource files for an application build; the > proposed solution is an md5 of the file contents so that the value persists > application restarts (or with whatever random string)
calculating an md5 of a file would induce additional computation time and we'd need to maintain hashes for each resource file. The prototype that I have now is a function in LiftRules that by default returns a random value generated on startup. Applications that needs MD5 per file could calculate that and maintain them. > > 2. Consolidation of CSS files on a given page for performance firstly, and > secondly for caching. > > Would there be times when people would not want the behaviour of 2? Im > generally not a huge fan of things that mess with user code or could provide > uneasy behaviour; im thinking specifically when people build there templates > where CSS values are overridden by values loaded after initial value ad > unless its munged together right, it might damage the expected behaviour > (think blueprint)...? Can I suggest we solve the caching problem using the > known hack of random strings, then deal with this proposal of resource > consolidation? What I'm playing with is" <lift:css.combine> <res:css name="abc.css"/> <res:css name="def.css"/> </lift:css.combine> under the hood this would be a function that return a Stream Response that "concatenates" the streams of files in questions serving them sequentially in the corresponding order. So from Lift's perspective there is no additional computation involved comparing with current situation except we serve desired resources in one response. To sum up the random string is what I think we should start with. IMO it is a fairly good solution that can evolve in time towards something else. > > Cheers > > Tim > > On 13 Feb 2010, at 08:45, Marius wrote: > > > > > > > On 12 feb., 23:04, Alex Black <[email protected]> wrote: > >>> Yes, that's how it should work if everything was configured correctly > >>> (which I think it wasn't for the OP) > > >> Heh, I'm the OP. > > >> I'll have to dig into why its not working as expected I guess. > > >>> But what we were discussing (at least I was :-) was more that Lift > >>> should serve resources with an "Expires" date in the far future. That > >>> way the browser will only make a single request for a resource (as > >>> long as the file is cached). This works well for returning visitors. > >>> But of course an updated resource should be fetched, hence the unique > >>> filenames. > > >> There are some things I like about that solution, but the unique > >> filenames just seems wrong. > > >> So I see that a far in the future expires works, but the reason you > >> need the unique filenames is because it doesn't really work. The far > >> in the future expires says "you can cache this for a long time cause > >> it won't change". > > >> The other option is say "you can cache this for like the next hour" > >> but every time you fetch it, you can tell me when you last got it > >> (conditional GET), and I won't send it to you if it hasn't changed > >> (304 not modified). This results in more requests, but no need for > >> unique filenames or anything, instead if the file changes then the > >> server will serve it up to whoever needs it. > > > It doesn't sound like today this solution is consistent on all "major" > > browsers. Can you confirm that it does? > > I used the query string solution in the past (like many others) and > > this works reasonably well. It is not a perfect solution > > but better then today. Besides if we want to adopt a different > > solution that would be pretty easy because this knowledge will be > > built > > in the snippet and the user code wont really change. > > >>> Combining individual files will improve load times for first time > >>> visitors by reducing the number of requests. > > >> That sounds like a great idea.. would like the same thing for JS. > >> Does the YUI compressor tool that lift uses with maven have this type > >> of feature? I Thought I read that it did. > > >>> /Jeppe > > > -- > > You received this message because you are subscribed to the Google Groups > > "Lift" group. > > To post to this group, send email to [email protected]. > > To unsubscribe from this group, send email to > > [email protected]. > > For more options, visit this group > > athttp://groups.google.com/group/liftweb?hl=en. -- You received this message because you are subscribed to the Google Groups "Lift" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/liftweb?hl=en.
