From mboxrd@z Thu Jan 1 00:00:00 1970 From: Alex Sassmannshausen Subject: bug#25045: [Website] Packages page takes too long to load Date: Tue, 29 Nov 2016 10:12:49 +0100 Message-ID: <87fumaps32.fsf@pompo.co> References: <878ts4jz8m.fsf@gnu.org> <87inr7pmj2.fsf@pompo.co> <87fumbmk8w.fsf@gnu.org> Reply-To: alex@pompo.co Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Return-path: Received: from eggs.gnu.org ([2001:4830:134:3::10]:39252) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1cBeTK-0004O6-Rz for bug-guix@gnu.org; Tue, 29 Nov 2016 04:13:10 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1cBeTG-0005pe-NU for bug-guix@gnu.org; Tue, 29 Nov 2016 04:13:06 -0500 Received: from debbugs.gnu.org ([208.118.235.43]:58419) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1cBeTG-0005pW-KL for bug-guix@gnu.org; Tue, 29 Nov 2016 04:13:02 -0500 Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1cBeTG-0000aP-AX for bug-guix@gnu.org; Tue, 29 Nov 2016 04:13:02 -0500 Sender: "Debbugs-submit" Resent-Message-ID: In-reply-to: <87fumbmk8w.fsf@gnu.org> List-Id: Bug reports for GNU Guix List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-guix-bounces+gcggb-bug-guix=m.gmane.org@gnu.org Sender: "bug-Guix" To: Ludovic =?UTF-8?Q?Court=C3=A8s?= Cc: Luis Felipe =?UTF-8?Q?L=C3=B3pez?= Acevedo , 25045@debbugs.gnu.org Ludovic Courtès writes: > Luis Felipe López Acevedo skribis: > >> On 2016-11-28 12:00, Alex Sassmannshausen wrote: >>> Hi Luis, >>> >>> Indeed, I had a first bash at solving this problem by providing a >>> set of >>> static html pages paginated by the first letter of the package name. >>> >>> I'm not particularly wedded to this solution, so if you feel strongly >>> about going another way, I'd be keen to hear/see about it. >>> >>> In the meantime, I'm open to testing/feedback. I will unfortunately >>> not >>> be able to put work into this until at least Saturday/Sunday, as some >>> Perl work has higher priority at the moment. >>> >>> But let me know if you have questions or feedback! >>> >>> Best wishes, >> >> Hi, Alex :) >> >> The solution I had in mind includes an alphabetic index, and >> pagination as well. However, it includes a few more things, and would >> take some time to design and implement. So I think we should use your >> patch to fix the size issue as soon as possible. > > I agree! > > Alex, was there anything left to address? If not, feel free to push. > :-) Having pushed some other stuff around my calendar, I should now be able to spend some time on polishing the patch tonight. >> For what is worth, this is what I had in mind: >> >> /packages/ >> First page of the list of packages. Packages listed here only provide >> a summary: package logo (if any), name, version, description, and an >> indicator if it has issues. This page also has filters to find >> packages (for now, alphabetic filter. In the future, category filter, >> and search box). >> >> /packages/page/N/ >> Page N of the list of packages. >> >> /packages/a/ >> First page of the list of packages whose name starts with A. Packages >> are presented the same way as in /packages/. >> >> /packages/a/page/N/ >> Page N of the list of packages starting with letter A. >> >> /packages/icecat/X.Y.Z/ >> Page with details about IceCat version X.Y.Z. It includes all the >> information about this package, including its issues (which are >> currently listed in a separate page along with the issues of other >> packages: /packages/issues.html). Including the issues of a package in >> its detail page could avoid having the current issues page grow too >> much, like the current Packages page. >> >> This static pagination and filtering would generate A LOT of pages, >> but of reasonable size for web browsers to load. The routing schema looks pretty neat to me! :-) > Sounds like a good plan as well, though that’s indeed a lot of web pages > for that rusty CVS repo to handle… > > Medium-term, I think we should consider a solution involving pages > generated on the fly server-side, with a caching proxy (nginx!) in front > of it. We’ll have to seek assistance from the gnu.org web masters, but > ISTR they were not against that idea. This sounds like a pretty good idea — though I probably won‘t have time to take the initiative here, I'm happy to do review and discussion of patches. Alex > > Thanks! > > Ludo’.