On 17.02.2007, at 18:39, Max Horn wrote: > > Am 17.02.2007 um 22:18 schrieb Christian Schaffner: > >> >>> In particular, I wonder -- do we really have to accept all these >>> params to the page? What are those used for? I.e. is anything ever >>> calling the package with an arch or dist set? If so, please tell me >>> where we do so. >> >> Right now, no. Why I had it like this is to have more readable links, >> e.g. >> >> http://www.finkproject.org/pdb/package.php/fink?version=0.26.1-31 >> >> makes a lot more sense than: >> >> http://www.finkproject.org/pdb/package.php/fink?pkg_id=9999 >> >> I like having urls that "mean" something to the end user. > > That's true, although I wonder what the advantage of that would be? > This might encourage users to play with the URL and try inserting > versions there manually, but that wouldn't work in general, of > course. What other advantage is there to the user being able to > "decypher" the URL in this way? > >> But, as you >> said, I am not sure if it is worth it. On the other hand, the queries >> into the db don't seem to be that bad as it is right now. > > Well, they sure are fast enough. However, when using pkg_id, the code > would become a lot shorter, and hence easier to maintain (and less > likely to contain bugs). > > BTW, note that with either approach, problems could occur if the user > bookmarks one of these URLs, and the pkg later is updated in the PDB. > Hence we must catch this case, and handle it appropriately (probably > by ignoring the params in this case).
Yep, this should be done. E.g. if 'pkg_id' and 'name' don't match, ignore 'pkg_id'. >>> I also added a TODO farther below: I added a $pkg_release which is >>> not yet used, but would allow getting rid of several other local >>> vars, and at least one auxiliary query (which I also marked with a >>> TODO). >> >> We definitely should do that. These local variables are there for >> historical reasons. What you propose is a lot nicer. > > I implemented and commited this change. There is a problem with your changes. Compare: http://www.finkproject.org/pdb/package.php/fink and http://finch.finkproject.org/~chris01/fink_web/pdb/package.php/fink Since you are no longer fetching all releases beforehand, there is no way to distinguish between a package not being in a bindist, or a bindist not being available at all. And the same problem exists for CVS/rsync dists. What do you think? > Just had another idea: We should consider limiting the number of > packages displayed on a page. After all, listing 7000 packages > generates a fairly big page, which is slow to load. Instead, how > about restricting to 100 pkgs per page or something like that?. Having a "Show Packages per Page" setting would be nice, although we also should have an (optional) show all button. Christian. ------------------------------------------------------------------------- Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys-and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV _______________________________________________ Fink-devel mailing list Fink-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/fink-devel
