From mboxrd@z Thu Jan 1 00:00:00 1970 From: lsworkemail112 at gmail.com (Luke SanAntonio) Date: Sat, 29 Sep 2012 15:16:55 -0400 Subject: [PATCH] Added code to output the age as seconds instead of "0 min." In-Reply-To: References: <1348878616-10065-1-git-send-email-lsworkemail112@gmail.com> Message-ID: "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 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 wrote: >> On Sat, Sep 29, 2012 at 8:43 PM, Luke SanAntonio >> 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.