{"thread":{"id":"6042","subject":"Re: [RFC] gitweb wishlist and TODO list (part 1)","startedAt":"2006-12-16T23:00:05Z","lastAt":"2006-12-21T09:18:20Z","messageCount":4,"participants":["Robert Fitzsimons","Jakub Narebski","Junio C Hamano"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"296663","messageId":"200612170000.06771.jnareb@gmail.com","threadId":"6042","inReplyTo":null,"subject":"[RFC] gitweb wishlist and TODO list (part 1)","fromName":"Jakub Narebski","fromEmail":"jnareb@gmail.com","sentAt":"2006-12-16T23:00:05Z","receivedAt":"2006-12-16T23:00:05Z","isPatch":false,"sender":{"key":"jnareb@gmail.com","avatar":"https://avatars.githubusercontent.com/u/2706?v=4"},"body":"This is yet another series of planned gitweb features. This part\nconcentrates on improving gitweb rather than on adding new features.\nComments appreciated.\n\nCopy send to Kernel.Org admin (which probably is most interested\nin improving gitweb and git performance), and to Petr Baudis which\nmaintains repo.or.cz public git hosting site, which runs new(est)\nversion of gitweb.\n\n1. Cleanup\n\n* HTML cleanup.\n\n There are still some places where we use presentational HTML elements\n like . I'd rather have it replaced by adding class to appropriate\n element, and adding proper rule to CSS. This would make changing the\n style easier, but it would make generated page larger.\n\n On the other hand we use class element when sometimes id attribute would\n be better, and sometimes (in the tables) it would be better served to\n add and elements, and use header attribute and select\n CSS style by this attribute value.\n\n* CSS cleanup.\n\n Use descendant selectors more, and use other selectors like parent or\n grandchild, instead of relying on class, to remove some of redundancy in\n CSS file. This would make ading similar elements easier (for example\n README for a project has now wrong style), and most probably would make\n CSS style smaller.\n\n Perhaps we should reorder CSS file, and add some comments, to make it's\n maintenance easier, and make it easier to add style for new elements.\n\n* Code cleanup.\n\n There is still a bit of code cleanup, especially in the subroutines\n which were not refactored yet. For example git_search should take\n advance of git-rev-list / git-log --grep, --author and --committer\n options, and split search output into pages. Untabify should perhaps be\n moved to esc_html, now that esc_path is separated... or perhaps not.\n\n\n2. Performance etc.\n\n* Better support for mod_perl in \"CGI mode\". Planned support for mod_perl\n in handler mode and support for FastCGI via CGI::Fast.\n\n Add support for mod_perl so it wouldn't need to be run with\n +ParseHeaders, and wouldn't need to set CGI environment variables. This\n can speed up gitweb a bit under mod_perl. The problem is how to do this\n to be able to run gitweb under CGI, FastCGI, mod_perl 1.0 and 2.0.\n\n This includes separating generating HTTP headers into separate\n subroutine, at first thin wrapper around \"print $cgi->header(...)\".\n\n* Native config reading.\n\n This could speed up gitweb a bit at least in configurations where\n repository is allowed to override default features (like blame,\n snapshot, pickaxe) and sometimes change their options.\n\n It would also allow to move some gitweb configuration, like description,\n homepage (in repo.or.cz), cloneurl from separate loose files in $GIT_DIR\n of a repository to it's proper place in the config. I'd rather add\n category as gitweb.category configuration variable than as yet another\n file in .git. Without native config reading it would be hard to add\n sensibly configureable committags support.\n\n The problem lies with lack of formal description of config file, and in\n git specific additions which make ready modules for INI config parsing\n infeasible. But it is not insurmountable. I think that config reader\n should be then incorporated in Git.pm module. We for sure need some\n tests for it added.\n\n By the way, should we always parse whole config file like in\n Tie::Memoize? Or read only one variable, if tieing it to hash then with\n Tie::Hash? Or some combination of both?\n\n* Cache validation and infinite cache for unchanging pages\n\n By itself cache validation would not bring much performance boost (for\n gitweb installations with large traffic), but with the reverse proxy,\n aka. caching engine, aka. HTTP accelerator in front of server this could\n help a lot.\n\n This means sending proper Last-Modifed: and ETag: (if HTTP/1.1) headers,\n and checking If-Modified-Since: and If-None-Match: headers, replying\n with 304 Not Modified. This should work both with gitweb called both as\n CGI script, and from mod_perl. While at it we should return always only\n HTTP header, without generating (if possible) and writing any contents\n on HEAD requests (and other which do not need body).\n\n The idea is to use query string (current arguments) with all hashes\n replaced by it's current value as sha1 for ETag, and to use committer\n date for Last-Modified. If possible, we could use stat info: date of\n last modification of given \"loose\" ref, or packed refs file, although\n that might be inaccurate. Not always we can check if cache is valid\n without calling any git command, but usually we would be able to do this\n after only a few commands. Implementing cache validation might mean that\n we would have to restructure code a bit.\n\n Separate subroutine for HTTP headers generation would help with writing\n cache validation.\n\n Bundled together is using \"infinite\" (or at least large: currently we\n use +1d) Expires: and/or Cache-Control: max-age (if HTTP/1.1) for\n unchanging pages. Although those pages are usually rarely accessed...\n\n\nNext parts: new features, improving existing views etc. in next email.\n\n-- \nJakub Narebski\n"},{"id":"294073","messageId":"7vfybf70op.fsf@assigned-by-dhcp.cox.net","threadId":"6042","inReplyTo":"200612170000.06771.jnareb@gmail.com","subject":"Re: [RFC] gitweb wishlist and TODO list (part 1)","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2006-12-17T01:47:50Z","receivedAt":"2006-12-17T01:47:50Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Jakub Narebski writes:\n\n> This is yet another series of planned gitweb features. This part\n> concentrates on improving gitweb rather than on adding new features.\n> Comments appreciated.\n>\n> Copy send to Kernel.Org admin (which probably is most interested\n> in improving gitweb and git performance), and to Petr Baudis which\n> maintains repo.or.cz public git hosting site, which runs new(est)\n> version of gitweb.\n\nTo be honest, I think the 0th item of this wishlist and TODO\nlist would be to find a sucker^Wvolunteer who will maintain the\ngitweb installation at kernel.org, for the message to be of any\ninterest to kernel.org admins.\n\n"},{"id":"29894","messageId":"20061221032216.GF17864@localhost","threadId":"6042","inReplyTo":"200612170000.06771.jnareb@gmail.com","subject":"Re: [RFC] gitweb wishlist and TODO list (part 1)","fromName":"Robert Fitzsimons","fromEmail":"robfitz@273k.net","sentAt":"2006-12-21T03:22:16Z","receivedAt":"2006-12-21T03:22:16Z","isPatch":false,"sender":{"key":"robfitz@273k.net","avatar":null},"body":"> * Cache validation and infinite cache for unchanging pages\n> \n> By itself cache validation would not bring much performance boost (for\n> gitweb installations with large traffic), but with the reverse proxy,\n> aka. caching engine, aka. HTTP accelerator in front of server this could\n> help a lot.\n\nThere is no need for extra servers to provide server side caching.\nApache2 includes suitable modules (mod_cache) which can be configured to\ncache in memory or disk the pages generated by gitweb.\n\nFor example the following apache2.conf entry will setup a 8MB mem cache\nwhich will return cached pages even if the user tries to force a refresh\nin their browser. The details are covered in the apache documentation\nhttp://httpd.apache.org/docs/2.2/caching.html .\n\n\n\tCacheDefaultExpire 60\n\tCacheIgnoreCacheControl On\n\tCacheIgnoreNoLastMod On\n\n\t\n\t\tCacheEnable mem /git/\n\t\tMCacheSize 8192\n\t\tMCacheMinObjectSize 512\n\t\tMCacheMaxObjectSize 128000\n\t\tMCacheRemovalAlgorithm LRU\n\t\n\n\nmod_cache will only cache pages with a query string in the url if they\nhave an expires header. So we can put a temporary hack in using\nmod_expires until gitweb sets an appropriate value.\n\n\n\tExpiresActive On\n\tExpiresDefault \"access plus 1 minutes\"\n\t...\n\n\nAlso the content type would need to be change to just return text/html\nor MSIE will do the wrong think if it's given a application/xhtml+xml\npage.\n\nRobert\n"},{"id":"29918","messageId":"200612211018.20796.jnareb@gmail.com","threadId":"6042","inReplyTo":"20061221032216.GF17864@localhost","subject":"Re: [RFC] gitweb wishlist and TODO list (part 1)","fromName":"Jakub Narebski","fromEmail":"jnareb@gmail.com","sentAt":"2006-12-21T09:18:20Z","receivedAt":"2006-12-21T09:18:20Z","isPatch":false,"sender":{"key":"jnareb@gmail.com","avatar":"https://avatars.githubusercontent.com/u/2706?v=4"},"body":"Robert Fitzsimons wrote:\n>> * Cache validation and infinite cache for unchanging pages\n>> \n>> By itself cache validation would not bring much performance boost (for\n>> gitweb installations with large traffic), but with the reverse proxy,\n>> aka. caching engine, aka. HTTP accelerator in front of server this could\n>> help a lot.\n\nBTW in mod_perl cache validation is as simple as using meets_condition()\nmethod on request object after we send at least one of validator\nheaders (Last-Modified:, ETag:)... but this would mean that cache\nvalidation would be available only when under mod_perl...\n\n> There is no need for extra servers to provide server side caching.\n> Apache2 includes suitable modules (mod_cache) which can be configured to\n> cache in memory or disk the pages generated by gitweb.\n[...]\n> mod_cache will only cache pages with a query string in the url if they\n> have an expires header. So we can put a temporary hack in using\n> mod_expires until gitweb sets an appropriate value.\n\n>From the discussion in the \n \"Re: kernel.org mirroring (Re: [GIT PULL] MMC update)\"\n http://thread.gmane.org/gmane.comp.version-control.git/33604\nthread Apache mod_cache doesn't bring much. Perhaps because of the above...\nalthough adding artificial expires header seems a bit like a hack.\n\n> Also the content type would need to be change to just return text/html\n> or MSIE will do the wrong think if it's given a application/xhtml+xml\n> page.\n\n>From gitweb.perl:\n\n # require explicit support from the UA if we are to send the page as\n # 'application/xhtml+xml', otherwise send it as plain old 'text/html'.\n # we have to do this because MSIE sometimes globs '*/*', pretending to\n # support xhtml+xml but choking when it gets what it asked for.\n\nThis was added by Alp Toker in f6801d669ee11:\n \"gitweb: Send XHTML as 'application/xhtml+xml' where possible\"\n\n-- \nJakub Narebski\nPoland\n"}]}