Modules only on CPAN
Hi to all, I check with master the modules that we need to install. Those 4 modules are not present in http://debian.koha-community.org Data::Pagination 0 * 0.44 No HTTPD::Bench::ApacheBench 0 * 0.73 No Test::WWW::Mechanize 0 * 1.44 No Archive::Extract 0.48 * 0.60 No Data::Pagination is used in Solr search Koha/SearchEngine/Solr/Search.pm and opac/search.pl HTTPD::Bench::ApacheBench is used in load_testing/benchmark_circulation.pl and in load_testing/benchmark_staff.pl Test::WWW::Mechanize is used in db_dependent/www/batch.t Archive::Extract is used in plugins/plugins-upload.pl and plugins/plugins-uninstall.pl and t/db_dependent/Plugins.t In my opinion Data::Pagination and Archive::Extract could be packages in http://debian.koha-community.org, the others no (because are only for developer). Cheers Zeno Tajoli -- Dr. Zeno Tajoli Dipartimento Gestione delle Informazioni e della Conoscenza z.tajoli@cineca.it fax +39 02 2135520 CINECA - Sede operativa di Segrate
Hi, On Fri, Dec 20, 2013 at 3:40 AM, Zeno Tajoli <z.tajoli@cineca.it> wrote:
In my opinion Data::Pagination and Archive::Extract could be packages in http://debian.koha-community.org, the others no (because are only for developer).
There's a problem with packaging Data::Pagination -- there is no copyright information documented with the module, meaning that a package could not be accepted into Debian proper. Attempts [1] by Robin and Tomás to get the maintainer to supply copyright and license statements have met with silence. That isn't a technical bar to building a .deb and putting it up on Koha's APT repo, but we should avoid doing so unless there is no other choice. However, there are other pagination modules available, including at least one (Data::Page) that is already packaged for Debian. There's only one script that uses Data::Pagination (and a module that imports it but doesn't use it), so making a switch shouldn't be very time consuming. It looks like Archive::Extract has been packaged for Jessie, so presumably making a backport to host on our APT repo would be feasible. [1] https://rt.cpan.org/Public/Bug/Display.html?id=80000 Regards, Galen -- Galen Charlton Manager of Implementation Equinox Software, Inc. / The Open Source Experts email: gmc@esilibrary.com direct: +1 770-709-5581 cell: +1 404-984-4366 skype: gmcharlt web: http://www.esilibrary.com/ Supporting Koha and Evergreen: http://koha-community.org & http://evergreen-ils.org
Hie, Could Data::Pagination be removed from master ? It is defined in Koha/SearchEngine/Solr/Search.pm but not used. It is only used in opac/search.pl. I think pagination should not be done into perl. We use JQuery Datatables for that. Regards, Le 20/12/2013 17:30, Galen Charlton a écrit :
Hi,
On Fri, Dec 20, 2013 at 3:40 AM, Zeno Tajoli <z.tajoli@cineca.it> wrote:
In my opinion Data::Pagination and Archive::Extract could be packages in http://debian.koha-community.org, the others no (because are only for developer).
There's a problem with packaging Data::Pagination -- there is no copyright information documented with the module, meaning that a package could not be accepted into Debian proper. Attempts [1] by Robin and Tomás to get the maintainer to supply copyright and license statements have met with silence.
That isn't a technical bar to building a .deb and putting it up on Koha's APT repo, but we should avoid doing so unless there is no other choice. However, there are other pagination modules available, including at least one (Data::Page) that is already packaged for Debian. There's only one script that uses Data::Pagination (and a module that imports it but doesn't use it), so making a switch shouldn't be very time consuming.
It looks like Archive::Extract has been packaged for Jessie, so presumably making a backport to host on our APT repo would be feasible.
[1] https://rt.cpan.org/Public/Bug/Display.html?id=80000
Regards,
Galen
-- Fridolin SOMERS Biblibre - Pôles support et système fridolin.somers@biblibre.com
It is only used in opac/search.pl.
I think pagination should not be done into perl. We use JQuery Datatables for that.
Perhaps, assuming you mean AJAX-loaded pagination, since bibliographic search results can potentially have hundreds of thousands of results. However, the OPAC ought to have a non-JavaScript fallback. -- Owen -- Web Developer Athens County Public Libraries http://www.myacpl.org
Hi, On Thu, Jan 30, 2014 at 7:52 AM, Owen Leonard <oleonard@myacpl.org> wrote:
It is only used in opac/search.pl.
I think pagination should not be done into perl. We use JQuery Datatables for that.
Perhaps, assuming you mean AJAX-loaded pagination, since bibliographic search results can potentially have hundreds of thousands of results. However, the OPAC ought to have a non-JavaScript fallback.
Agreed, there is a place for server-calculated pagination. I also agree that Data::Pagination needs to be replaced. Regards, Galen -- Galen Charlton Manager of Implementation Equinox Software, Inc. / The Open Source Experts email: gmc@esilibrary.com direct: +1 770-709-5581 cell: +1 404-984-4366 skype: gmcharlt web: http://www.esilibrary.com/ Supporting Koha and Evergreen: http://koha-community.org & http://evergreen-ils.org
Ok, I see. For search results indeed we make pagination in perl. But we should use code existing in opac-search.pl to be able to remove Data::Pagination, or use a debian-packaged module. Le 30/01/2014 17:00, Galen Charlton a écrit :
Hi,
On Thu, Jan 30, 2014 at 7:52 AM, Owen Leonard <oleonard@myacpl.org> wrote:
It is only used in opac/search.pl.
I think pagination should not be done into perl. We use JQuery Datatables for that.
Perhaps, assuming you mean AJAX-loaded pagination, since bibliographic search results can potentially have hundreds of thousands of results. However, the OPAC ought to have a non-JavaScript fallback.
Agreed, there is a place for server-calculated pagination. I also agree that Data::Pagination needs to be replaced.
Regards,
Galen
-- Fridolin SOMERS Biblibre - Pôles support et système fridolin.somers@biblibre.com
Throwing down the gauntlet here in a bit of a stream of conscience... If search results are all we are paginating server-side then shouldn't we really be focusing on search relevancy and limiting results down such that we don't really need to paginate at all? (I'm kinda hoping that the elastic search work will go a long way to solving this dilemma...) I would put money on analytic's showing that most users give up after page two or three of the results at the latest. I do think some page's need pagination, like the acquisitions pages for example.. but the search results in my mind should be a bit more concise and accurate in the first place ;) Either way, this is going off topic somwhat Just my two pennies... Martin Renvoize Software Engineer, PTFS Europe Ltd Content Management and Library Solutions Skype: Landline: 0203 286 8685 Mobile: 07725985636 http://www.ptfs-europe.com On 31 January 2014 08:08, Fridolin SOMERS <fridolin.somers@biblibre.com>wrote:
Ok, I see. For search results indeed we make pagination in perl. But we should use code existing in opac-search.pl to be able to remove Data::Pagination, or use a debian-packaged module.
Le 30/01/2014 17:00, Galen Charlton a écrit :
Hi,
On Thu, Jan 30, 2014 at 7:52 AM, Owen Leonard <oleonard@myacpl.org> wrote:
It is only used in opac/search.pl.
I think pagination should not be done into perl. We use JQuery Datatables for that.
Perhaps, assuming you mean AJAX-loaded pagination, since bibliographic search results can potentially have hundreds of thousands of results. However, the OPAC ought to have a non-JavaScript fallback.
Agreed, there is a place for server-calculated pagination. I also agree that Data::Pagination needs to be replaced.
Regards,
Galen
-- Fridolin SOMERS Biblibre - Pôles support et système fridolin.somers@biblibre.com _______________________________________________ Koha-devel mailing list Koha-devel@lists.koha-community.org http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel website : http://www.koha-community.org/ git : http://git.koha-community.org/ bugs : http://bugs.koha-community.org/
Hi, On Fri, Jan 31, 2014 at 1:05 AM, Martin Renvoize < martin.renvoize@ptfs-europe.com> wrote:
If search results are all we are paginating server-side then shouldn't we really be focusing on search relevancy and limiting results down such that we don't really need to paginate at all? (I'm kinda hoping that the elastic search work will go a long way to solving this dilemma...) I would put money on analytic's showing that most users give up after page two or three of the results at the latest.
I would not be surprised that there is evidence that most users, most of the time, don't go past the first page or so of search results. However, "most" is not "everybody" and is not "every time", and is decidedly not "the librarians who are among Koha's users, and who have legitimate search needs that are different from most patrons". I do not have confidence that any search engine that exists now is going to solve the relevance problem perfectly until the advent of both real strong AI and telepathy. (And we might discover we have ... other problems should a strong AI arise ;) ). I also don't foresee Google dropping search result paging any time soon. That's not to say that we shouldn't look at all avenues of improving search result sorting, but I do suggest that a separate thread would be better for discussing that. Regards, Galen -- Galen Charlton Manager of Implementation Equinox Software, Inc. / The Open Source Experts email: gmc@esilibrary.com direct: +1 770-709-5581 cell: +1 404-984-4366 skype: gmcharlt web: http://www.esilibrary.com/ Supporting Koha and Evergreen: http://koha-community.org & http://evergreen-ils.org
participants (5)
-
Fridolin SOMERS -
Galen Charlton -
Martin Renvoize -
Owen Leonard -
Zeno Tajoli