J.H. wrote: > On 03/21/2011 09:01 AM, Jakub Narebski wrote: > > First, it would complicate caching, as output would depend not only purely > > on URL, but can also depend on cookies. Cache key would have to take it > > into account. > > > > Second, it would reduce effectiveness of cache, as single page would have > > to have multiple versions (up to 24, one per timezone, I guess). > > The implementation I have running in the back of my head would be > completely independent, so I'm not sure what implementation you are > thinking of that would cause this. One of the reasons I'm suggesting > Javascript at all is to avoid exactly this problem. Well, of course if output is the same, only post-processed by JavaScript (and no server-side fallback), then there is no interference between timezones and output caching. N.B. caching of git output, or of parsed data, allows to generate multiple outputs from one cached value... but OTOH output caching is simpler. [...] > > Well, if we are doing it on server side, then by having 'timezone' feature > > rather than 'localtime' one from Kevin patches, we would have per-repo > > configuration "for free". > > Doing it on the server overly complicates things, breaks web caches, > gitweb-caching and generally I'd argue is not what we want. It would > work for small installations, in particular those not using > gitweb-caching, but honestly this is a useful enough feature for a more > distributed audience it needs to work with gitweb-caching, without > putting undue burden on the caching engine (as a whole). Javascript is > the obvious, and simple answer to that. Won't add any substantial > complexity to the backend, and will allow for more complex choices and > instant changes (without involving the backend at all). > > That pretty much sounds like a win to me anyway... Note that proposed "on server" solution, like the one in Kevin's patches, would not include a way to select a way of presenting dates by client: it all would be set on server, and not interfere with output caching. As to complexity: you would either have complexity in backend, or complexity in JavaScript... But I agree that JavaScript enhancement solution is better. > > > I would think, if we are doing this in JavaScript, that this is an over > > > complication to do on a per-repo basis. I would guess setting a generic > > > default and letting people deviate makes more sense. Just my thought > > > anyway, but I think there's a lot of extra per-repo configurations that > > > add complexity with minimal gain. > > > > It it is set _by client_, then of course it doesn't make much sense to > > make it configurable per-repository. Besides it would be difficult to > > implement and store in JavaScript, I think. > > Cookies solve the problem, and those are basically trivial to deal with > in Javascript. I was talking about difficulty of _per-repo_ configuration with _client-side_ scripting. For each [visited] repository we would have to store config: too much for a cookie (well, perhaps localStorage... ;-)). > > Per-repository settings makes sense for _server-side_; different > > repositories may have different character: some might be geographically > > distributed, some might have all contributors in single timezone. > > Agreed, since I've been arguing for the client side work, I think we are > on the same page here. [...] > Also keeping in mind that miroformats are almost explicitly for the > benefit of search engines, which I'm not sure if a majority of gitweb > installations care about, it may not be worthwhile to actually go down > that road. Right. > > > > Note that JavaScript mangling of dates is quite independent on whether > > > > dates are displayed in GMT/UTC or in author / committer / tagger timezone > > > > like for current 'localtime' feature. > > > > > > I wasn't intending to change the current formatting of the times we have > > > in place currently. Just allowing people to change what time was being > > > displayed. > > > > I wanted to say that JavaScript post-processing of dates is a bit > > orthogonal to David's server-side localtime (or similar) feature. > > It's a different direction, yes, but it's definitely not orthogonal. If > you do this on the server side, as David originally suggested, you can > create a mess in other places (external proxies, external web caches, > gitweb-caching, etc). I like his idea, just not where it's implemented > at current. If you leave the server side alone, and deal with the > processing of the dates on the client side you alleviate all of the > server side gotchas, while only introducing one or two gotchas to the > client side. > > This isn't an orthogonal discussion, it's a discussion of where the > right place / right solution to accomplish the same goal is. Well, perhaps it is not orthogonal discussion, but you can those two _slightly different_ solutions: * server-side, per-repository config, no client choice * client-side, JavaScript enhancements, global per-client choice, client choice stored in cookie might work together... though it probably doesn't make much sense. -- Jakub Narebski Poland -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html