>> <!-- >> Full URL: |http://localhost/gitweb-caching/gitweb.cgi?p=/project.git;a=summary| >> URL Hash: |7a31cfb8a43f5643679eec88aa9d7981| >> --> > > Nice idea. It helps with debugging and doesn't introduce information > leakage. That was the plan, and I've already got a scenario where it would be useful. >> The first bit tells you what the url that generated the page actually was, the second is >> the hash used to store the file with the first two characters being used as the directory: >> >> <cachedir>/7a/31cfb8a43f5643679eec88aa9d7981 > > Isn't it > > <cachedir>/7a/7a31cfb8a43f5643679eec88aa9d7981 > > in your series? Nope our $fullhashdir = "$cachedir/". substr( $urlhash, 0, 2) ."/"; and then a couple of lines later: $fullhashpath = "$fullhashdir/". substr( $urlhash, 2 ); right at the top of cache_fetch() >> Also useful for greping through the existing cache and finding files with unique paths that >> you may want to explicitly flush. > > Though probably better 'cache_admin' page would be ultimately best > solution, see proof of concept in The biggest problem with the cache admin page you've got there, is that gitweb itself doesn't have a framework for user administration, privileges, etc. Limiting it to the local machine is also useless, there are very few people who are going to have access, from 127.0.0.1 to their web server, and this also breaks anything even remotely resembling virtual hosts. The fact that it's unusable from virtual hosts makes this pretty much DOA. Like I've said in the past, we need to at least look at web frameworks for gitweb, and if we want to provide things like the admin page than we need to consider that we are going to need user management. That, in particular, starts drifting towards needing a database to store things in and I for one am *NOT* in favor of that. I like the idea of a framework helping deal with things like page layout, separating data access from content, etc. I do not like the idea of gitweb having a full blown setup with a database and all behind it. - John 'Warthog9' Hawley -- 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