Re: [PATCH v4 2/2] gitweb: introduce localtime feature

J.H. wrote:

On 03/21/2011 09:01 AM, Jakub Narebski wrote:

quoted

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.

[...]

quoted

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.

quoted

quoted

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... ;-)).
 

quoted

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.
 

quoted

quoted

quoted

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