On Sun, 2008-05-11 at 00:32 +0200, Jakub Narebski wrote: > On Sun, 10 May 2008, J.H. <warthog19@xxxxxxxxxxxxxx> wrote: > > > $page_size should be moved to a configuration directive, with a possible > > default of 100, and there should be an option to turn it off completely > > (I.E. kernel.org will likely have it turned off). > > If it would be configurable (and I agree that it is probably a good > idea), it should be per gitweb instance (i.e. global variable), and > should perhaps be named $project_list_page_size to distinguish it from > number of items shown (page size) for 'shortlog', 'log' and 'history' > views. > > I guess that value of 0, or perhaps of undef would mean to not divide > projects list, or project search results, into pages. > > BTW. why do you think that kernel.org would be better to have project > list pagination turned off? If we have caching on I'd rather leave it as a single page, much easier to search on and with firefox /<project or name> then <ctrl>+g a couple of times is really fast to find what I need. Also means less to cache (good for us) and faster access for most. I'm going to guess leaving it as a single page, unless it gets *very* unwieldy, will be how we leave it. > > > It might also be advantageous to generate the entire list and stash that > > somewhere, (session on the host side?) and run the pagination out of > > that. > > First, when using $projectslist file with new (second patch in series, > "gitweb: Allow project description in project_index file" most of data > (well, all except age) would be filled by parsing single file. > > Second, the idea is to cache results of filled in @$projlist e.g. using > Storable, i.e. cache Perl data and not final HTML output. I approve of that plan, caching all the html is kinda expensive *hides the 20G of gitweb cache he has* > > > Would even allow the user to choose how many items they wish to > > see from a drop down maybe? > > I think it is also a good idea, at least for search results. > > > NOTE that this was an RFC patch, meant mainly to provide comments on > what to improve... I know, that's why I'm chiming in with my thoughts, I like the idea and bonus points go to the user configurable display on that. There are definitely sites that can benefit from this and likely at some point k.org is going to need have to paginate - just not sure when that point is going to get hit. - 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
