Hi all, Patch 5636 should be next in passing qa now, but these questions remained open: Style question to the community: should core pages in the staff client (like tools/cleanborrowers.pl) have both a templated page in the staff client AND a command-line presence, or should the commandline tool be a separate script in misc/? At this time, there doesn't seem to be any precedent for inclusion in the core script. Before passing this patch for QA, I'd like to get some feedback, as this may both open doors for us, as well as create additional work to create consistency of implementation for existing jobs. Please respond if you want to share your opinion on this subject. Thanks. Marcel
Hi all, Il 12/12/2011 14:06, Marcel de Rooy ha scritto:
Patch 5636 should be next in passing qa now, but these questions remained open:
Style question to the community: should core pages in the staff client (like tools/cleanborrowers.pl) have both a templated page in the staff client AND a command-line presence, or should the commandline tool be a separate script in misc/?
My idea is yes, we can have scripts with a templated page AND a command-line presence. We need only to insert it in http://manual.koha-community.org/3.6/en/cronjobsch.html Bye Zeno Tajoli -- Dott. Zeno Tajoli tajoliAT_SPAM_no_prendiATcilea.it fax +39 02 2135520 CILEA - Consorzio Interuniversitario http://www.cilea.it/disclaimer
2011/12/12 Marcel de Rooy <M.de.Rooy@rijksmuseum.nl>:
Hi all,
Patch 5636 should be next in passing qa now, but these questions remained open:
Style question to the community: should core pages in the staff client (like
tools/cleanborrowers.pl) have both a templated page in the staff client AND a command-line presence, or should the commandline tool be a separate script in misc/?
At this time, there doesn't seem to be any precedent for inclusion in the core script. Before passing this patch for QA, I'd like to get some feedback, as this may both open doors for us, as well as create additional work to create consistency of implementation for existing jobs.
Please respond if you want to share your opinion on this subject.
I think functionality should be included in C4 or Koha, and exposed by both command-line tool and templated front-ends. Also, any command-line tool should honour system preferences by default, and the user be warned if using parameters others than default. Regards To+
Tomas Cohen Arazi <tomascohen@gmail.com>
I think functionality should be included in C4 or Koha, and exposed by both command-line tool and templated front-ends. Also, any command-line tool should honour system preferences by default, and the user be warned if using parameters others than default.
I agree with this. I'd much prefer command-line tools outside the web folders. If they have logic in common, that logic should be in the modules, which should make the two interfaces pretty simple. Hope that helps, -- MJ Ray (slef), member of www.software.coop, a for-more-than-profit co-op. http://koha-community.org supporter, web and library systems developer. In My Opinion Only: see http://mjr.towers.org.uk/email.html Available for hire (including development) at http://www.software.coop/
Le 12/12/2011 14:06, Marcel de Rooy a écrit :
Hi all, Patch 5636 should be next in passing qa now, but these questions remained open: Style question to the community: should core pages in the staff client (like
tools/cleanborrowers.pl) have both a templated page in the staff client AND a command-line presence, or should the commandline tool be a separate script in misc/? At this time, there doesn't seem to be any precedent for inclusion in the core
script. Before passing this patch for QA, I'd like to get some feedback, as this may both open doors for us, as well as create additional work to create consistency of implementation for existing jobs.
My comment here : if an ENH don't break any existing behaviour, do what it announces, and is consistent with existing features and code, then we must welcome any patch and don't request for an improvement of the improvement: if you want more, just do it yourself, everybody is acting on a volunteer basis ! In this case (speaking as RM here, not as owner of the company submitting the patch ;-) ), it should just be "passed QA", as it passes the 3 questions: don't break existing behaviour, do what it announces, consistent with existing feature & code. (double check if there can be a security issue !) -- Paul POULAIN http://www.biblibre.com Expert en Logiciels Libres pour l'info-doc Tel : (33) 4 91 81 35 08
My difficulty with this patch is that it sets precedent for implementing both commandline and staff client interfaces for a single script. Up until now, that's not be the case (as far as my research has shown; counter-examples welcome). I just think we need, for consistency sake, to either make this the standard practice, or require separate cronjobs. So, I don't have any issue with the feature, but the potential shift in coding practices that the patch represents. Is the rest of the Koha developer community comfortable with having dual-purpose scripts like this? Are there are any best practices that can be cited for or against such practice? Cheers, -Ian On Mon, Dec 12, 2011 at 11:07 AM, Paul Poulain <paul.poulain@biblibre.com>wrote:
Le 12/12/2011 14:06, Marcel de Rooy a écrit :
Hi all, Patch 5636 should be next in passing qa now, but these questions remained open: Style question to the community: should core pages in the staff client (like
tools/cleanborrowers.pl) have both a templated page in the staff client AND a command-line presence, or should the commandline tool be a separate script in misc/? At this time, there doesn't seem to be any precedent for inclusion in the core
script. Before passing this patch for QA, I'd like to get some feedback, as this may both open doors for us, as well as create additional work to create consistency of implementation for existing jobs.
My comment here : if an ENH don't break any existing behaviour, do what it announces, and is consistent with existing features and code, then we must welcome any patch and don't request for an improvement of the improvement: if you want more, just do it yourself, everybody is acting on a volunteer basis !
In this case (speaking as RM here, not as owner of the company submitting the patch ;-) ), it should just be "passed QA", as it passes the 3 questions: don't break existing behaviour, do what it announces, consistent with existing feature & code. (double check if there can be a security issue !)
-- Paul POULAIN http://www.biblibre.com Expert en Logiciels Libres pour l'info-doc Tel : (33) 4 91 81 35 08
-- Ian Walls Lead Development Specialist ByWater Solutions ALA Midwinter Booth #2048 Phone # (888) 900-8944 http://bywatersolutions.com ian.walls@bywatersolutions.com Twitter: @sekjal
Le 12/12/2011 17:24, Ian Walls a écrit :
My difficulty with this patch is that it sets precedent for implementing both commandline and staff client interfaces for a single script. Up until now, that's not be the case (as far as my research has shown; counter-examples welcome). I just think we need, for consistency sake, to either make this the standard practice, or require separate cronjobs.
So, I don't have any issue with the feature, but the potential shift in coding practices that the patch represents. Is the rest of the Koha developer community comfortable with having dual-purpose scripts like this? Are there are any best practices that can be cited for or against such practice? As I said already (on the ML iirc), there are only a very few cases where this should be relevant. So I think it's not worth spending too much time deciding if it should be a rule or not -- Paul POULAIN http://www.biblibre.com Expert en Logiciels Libres pour l'info-doc Tel : (33) 4 91 81 35 08
Ian, My difficulty with this patch is that it sets precedent for implementing
both commandline and staff client interfaces for a single script. Up until now, that's not be the case (as far as my research has shown; counter-examples welcome). I just think we need, for consistency sake, to either make this the standard practice, or require separate cronjobs.
So, I don't have any issue with the feature, but the potential shift in coding practices that the patch represents. Is the rest of the Koha developer community comfortable with having dual-purpose scripts like this? Are there are any best practices that can be cited for or against such practice?
I'm not really sure why this should be an issue. Consistency is nice, but it seems to me there are very few scripts that would be usable both via server and via command line, simply because the different requirements of the two. So consistency won't be greatly impacted. The important thing is making sure that things are documented (and this script is documented, though I suppose POD would be even nicer, if someone was in the mood.). If a script can handle either option, though, I see no reason not to. Provided the bulk of the work is done in the C4 or Koha namespace, which, for this patch, is true. Regards, Jared -- Jared Camins-Esakov Bibliographer, C & P Bibliography Services, LLC (phone) +1 (917) 727-3445 (e-mail) jcamins@cpbibliography.com (web) http://www.cpbibliography.com/
Hi, On 12/12/2011 11:24 AM, Ian Walls wrote:
My difficulty with this patch is that it sets precedent for implementing both commandline and staff client interfaces for a single script. Up until now, that's not be the case (as far as my research has shown; counter-examples welcome). I just think we need, for consistency sake, to either make this the standard practice, or require separate cronjobs.
I think it goes beyond just consistency. Without having looked at the particular script in question, most/all command-line scripts produce output files. No big deal, right? But if the script can also run as a CGI script, keep in mind that it runs with the same privileges as the whatever user the webserver is running as. If such a script has a bug that allows it to be run by Apache *and* invoke one or more of the command-line output file options, in principle it could scribble over other files. Such an attack may be more theoretical than real, but my preference would be that if a script's logic should be accessible from the command line and the web interface, to put the logic in the API and have the CGI and CLI scripts just be thin wrappers. Regards, Galen -- Galen Charlton Director of Support and 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
On Mon, Dec 12, 2011 at 12:07 PM, Galen Charlton <gmc@esilibrary.com>wrote:
Hi,
Such an attack may be more theoretical than real, but my preference would be that if a script's logic should be accessible from the command line and the web interface, to put the logic in the API and have the CGI and CLI scripts just be thin wrappers.
I agree with this concern particularly, but also agree that scripts should be light-weight and "vanilla" as possible. So +1 for having the logic in C4 and separate scripts to call it from there. Kind Regards, Chris
Le 12/12/2011 17:24, Ian Walls a écrit :
My difficulty with this patch is that it sets precedent for implementing both commandline and staff client interfaces for a single script. Up until now, that's not be the case (as far as my research has shown; counter-examples welcome). I just think we need, for consistency sake, to either make this the standard practice, or require separate cronjobs.
So, I don't have any issue with the feature, but the potential shift in coding practices that the patch represents. Is the rest of the Koha developer community comfortable with having dual-purpose scripts like this? Are there are any best practices that can be cited for or against such practice?
Cheers,
-Ian
Hi, in my opinion, it is not "dual-purpose" script, command-line or web interface, it is the same process you want. duplicating code and editing to make the code commandline compliant would be far harder to maintain and keep synched than having the script callable via command-line and web. In my opinion, we have enough exemples of copy paste edit code in Koha, to see how un maintainable that behaviour is and to be willing to restrain from that from now on. This is my opinion. cheers -- Henri-Damien LAURENT
On Mon, Dec 12, 2011 at 11:07 AM, Paul Poulain <paul.poulain@biblibre.com <mailto:paul.poulain@biblibre.com>> wrote:
Le 12/12/2011 14:06, Marcel de Rooy a écrit : > Hi all, > Patch 5636 should be next in passing qa now, but these questions > remained open: > Style question to the community: should core pages in the staff client > (like > > tools/cleanborrowers.pl <http://cleanborrowers.pl>) have both a templated page in the staff client > AND a > command-line presence, or should the commandline tool be a separate > script in misc/? > At this time, there doesn't seem to be any precedent for inclusion in > the core > > script. Before passing this patch for QA, I'd like to get some feedback, as > this may both open doors for us, as well as create additional work to create > consistency of implementation for existing jobs.
My comment here : if an ENH don't break any existing behaviour, do what it announces, and is consistent with existing features and code, then we must welcome any patch and don't request for an improvement of the improvement: if you want more, just do it yourself, everybody is acting on a volunteer basis !
In this case (speaking as RM here, not as owner of the company submitting the patch ;-) ), it should just be "passed QA", as it passes the 3 questions: don't break existing behaviour, do what it announces, consistent with existing feature & code. (double check if there can be a security issue !)
-- Paul POULAIN http://www.biblibre.com Expert en Logiciels Libres pour l'info-doc Tel : (33) 4 91 81 35 08
-- Ian Walls Lead Development Specialist ByWater Solutions ALA Midwinter Booth #2048 Phone # (888) 900-8944 http://bywatersolutions.com ian.walls@bywatersolutions.com <mailto:ian.walls@bywatersolutions.com> Twitter: @sekjal
_______________________________________________ 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/
On 13 December 2011 06:11, LAURENT Henri-Damien <laurenthdl@alinto.com> wrote:
Hi, in my opinion, it is not "dual-purpose" script, command-line or web interface, it is the same process you want. duplicating code and editing to make the code commandline compliant would be far harder to maintain and keep synched than having the script callable via command-line and web. In my opinion, we have enough exemples of copy paste edit code in Koha, to see how un maintainable that behaviour is and to be willing to restrain from that from now on. This is my opinion.
I agree, if code is used in more than one place it should be in a module, in fact our scripts should be as lightweight as possible and as close to simple wrappers for functionality in perl modules. So I agree that we should not copy paste code, but we should cut and paste it into modules and have the scripts use it from there. Chris
Paul Poulain <paul.poulain@biblibre.com>
In this case (speaking as RM here, not as owner of the company submitting the patch ;-) ), it should just be "passed QA", as it passes the 3 questions: don't break existing behaviour, do what it announces, consistent with existing feature & code. (double check if there can be a security issue !)
Consistent with existing code? What existing code implements a dual web/command-line interface? Thanks for any clarification, -- MJ Ray (slef), member of www.software.coop, a for-more-than-profit co-op. http://koha-community.org supporter, web and library systems developer. In My Opinion Only: see http://mjr.towers.org.uk/email.html Available for hire (including development) at http://www.software.coop/
participants (11)
-
Chris Cormack -
Chris Nighswonger -
Galen Charlton -
Ian Walls -
Jared Camins-Esakov -
LAURENT Henri-Damien -
Marcel de Rooy -
MJ Ray -
Paul Poulain -
Tomas Cohen Arazi -
Zeno Tajoli