> 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.
Hi Marius, what does the proposed token represent? It looks to me like it represents a given resource (css file) per running instance of Jetty. By using MD5 it instead represents the file itself. Problems with using a token that represents a given resource per running instance of jetty: - if the server restarts you use a new token, so all clients are forced to re-get the 'new' resource - if you run more than one server, then each server has different tokens, so clients think there are different resources I also like the suggestion that a solution to the consolidation problem be kept separate from the problem of generating unique urls for cachable resources (such as CSS, javascript, etc). > > > > > 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.
