"reflect the actual data up-to-date" should be: "reflect the actual, up-to-date data..."
Sorry about that... On Sat, Sep 29, 2012 at 3:14 PM, Luke SanAntonio <[email protected]> wrote: > Okay, I understand now. > I guess my take on the matter is a user who selects caching already has > accepted > that the data generated might not correctly reflect the actual data > up-to-date... these users > know it going in, so I don't think it's a huge concern... > > Sorry about my previous misunderstanding... > - Luke > > On Sat, Sep 29, 2012 at 2:51 PM, Jason A. Donenfeld <[email protected]> wrote: >> On Sat, Sep 29, 2012 at 8:43 PM, Luke SanAntonio >> <[email protected]> wrote: >>> Hi Jason, >>> >>> First of all, good call with the cache, it hadn't even crossed my >>> mind... >>> Second I think the cache isn't something we need to worry about... >>> mostly because >>> cgit is very lightweight, and I think for now, we don't have to be too >>> worried about >>> performance, correct me if I'm wrong though... Also it seems to me >>> that with or without the cache, >>> every cgit page I've ever come across seems to load in much less time >>> than a second... >> >> >> Hey, sorry, just to be clear -- my concern isn't about performance, >> but about this: >> >> If you set the cgit cache to 1 minute, and the granularity of >> timestamps is only 1 minute, then for the most part, the pages, though >> cached, will see up to date. >> >> However if you set the cgit cache to 1 minute, and the granularity of >> the timestamps is 1 second, then for the most part, the pages will >> seem out of date. >> >> But this is just how caching is, so I'm not sure it's such a big >> concern. Just throwing it out there, in case anyone had some elegant >> solution or attitude about it. _______________________________________________ cgit mailing list [email protected] http://hjemli.net/mailman/listinfo/cgit
