<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN"><html><head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8"></head><body>A new request with request id 7893 has been created by koha-devel-request@lists.koha-community.org. Short info on the request is : <br><br>Title : Koha-devel Digest, Vol 201, Issue 15<br>Category : <br>Description : <div>Send Koha-devel mailing list submissions to<br> koha-devel@lists.koha-community.org<br><br>To subscribe or unsubscribe via the World Wide Web, visit<br> https://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel<br>or, via email, send a message with subject or body 'help' to<br> koha-devel-request@lists.koha-community.org<br><br>You can reach the person managing the list at<br> koha-devel-owner@lists.koha-community.org<br><br>When replying, please edit your Subject line so it is more specific<br>than "Re: Contents of Koha-devel digest..."<br><br><br>Today's Topics:<br><br> 1. Re: Serving Intranet from a subpath (Thomas Klausner)<br> 2. Re: Serving Intranet from a subpath (dcook@prosentient.com.au)<br> 3. Mojolicious controllers for Koha plugins<br> (dcook@prosentient.com.au)<br><br><br>----------------------------------------------------------------------<br><br>Message: 1<br>Date: Mon, 15 Aug 2022 13:56:52 +0200<br>From: Thomas Klausner <domm@plix.at><br>To: koha-devel@lists.koha-community.org<br>Subject: Re: [Koha-devel] Serving Intranet from a subpath<br>Message-ID: <20220815115652.GX864217@plix.at><br>Content-Type: text/plain; charset=utf-8<br><br>Hi!<br><br>On Mon, Aug 15, 2022 at 10:02:18AM +1000, dcook@prosentient.com.au wrote:<br>> I feel like we've had this conversation before but now I can't find a record of it...<br><br>Yes, we had the same problem with OPAC, and "solved" it there with a <br>HTML-Rewriting middleware (not very stable, but good enough for now)<br><br>> I was intrigued by that "base" suggestion, but there's a few issues with it:<br><br>`base` is indeed very tricky had can have weird corner cases. But if it <br>would have been an easy fix, I'd go with it. But as `base` is not <br>working for our uses cases (without having to touch all links/templates) <br>I think it's not the best option.<br><br>> Personally, I'm in favour of using "uri_for()" template methods, which <br>> are common in pretty much every web framework around today, but it <br>> would probably be a prohibitive amount of work.<br><br>A lot work, yes (though I guess that 99% can be done with a few regex, <br>but the hard part will be finding the corner cases that did not work). <br>But the Steiermärkische Landesbibliothek is willing to do that work.<br><br>> I also wonder how it <br>> might affect some of the latest Vue.js work that Jonathan has been <br>> doing. <br><br>I don't know a lot about how that app is implemented, but usually the <br>Vue.js app will have its own internal routing and will "only" need to <br>know two things:<br>* where is the API the app should be talking to?<br>* where are the vue.js source files and other assets located<br><br>I also did not take a look how the Mojo API is connected with the rest <br>and if / which paths need to be adapted there (though as Mojo provides <br>`uri_for` I assume it will be simple)<br><br>> I'd love to get rid of "/cgi-bin/koha" one day in any case, since it's a holdover from decades past...<br><br>Yes, if we generate links via a function, we could easily get rid of <br>`/cgi-bin/koha` in the same go :-)<br><br>> Ultimately, I think only the RM can answer this one. <br><br>And how can I get the RM to think about this issue, so we might get an <br>answer (sorry, I'm still not that integrated into the Koha community..)<br><br>Greetings,<br>domm<br><br>-- <br>#!/usr/bin/perl https://domm.plix.at<br>for(ref bless{},just'another'perl'hacker){s-:+-$"-g&&print$_.$/}<br><br><br>------------------------------<br><br>Message: 2<br>Date: Tue, 16 Aug 2022 09:51:01 +1000<br>From: <dcook@prosentient.com.au><br>To: "'Thomas Klausner'" <domm@plix.at>,<br> <koha-devel@lists.koha-community.org><br>Cc: "'Tomas Cohen Arazi'" <tomascohen@theke.io><br>Subject: Re: [Koha-devel] Serving Intranet from a subpath<br>Message-ID: <010f01d8b101$ed0d5ff0$c7281fd0$@prosentient.com.au><br>Content-Type: text/plain; charset="utf-8"<br><br>When I say it's a lot of work, I mean more so in terms of testing and QA than the writing/authoring of the patch. <br><br>If you did a huge patch with a bunch of link changes via regex, no one would probably test it, because it would be too hard to thoroughly test. (And then it would be difficult for you to keep rebasing to keep up with Koha as it changed.)<br><br>If I were you... I'd probably do a patch for the core uri_for() mechanism, and then propose adding a Coding Guideline that requires using it instead of hard-coded links like "/cgi-bin/koha/..." going forward. And then once that is part of Koha, then I'd open up targeted reports that look at updating the templates for say a particular module (e.g. Circulation, Cataloguing, Reports, etc) and go one by one. You could also try to recruit people to your cause for testing and QA. While I don't have a particular need for serving Koha via a subpath, I do find it interesting, so I'd be willing to do some testing/QA. I don't know that I have stamina to do the entire staff interface though... as that's over 400 templates.<br><br>Another thought would be to first target the OPAC, since it has far fewer templates to update. Once it's been proven in the OPAC, it might be easier to convince people for the staff interface too, and maybe QA/RM would be willing to make changes with less rigorous testing, since it was already a proven change. <br><br>As for bringing it to the attention of the RM, I've been around the Koha community for 10.5 years, and I still don't have an answer for that one 😉. You're in a good time zone, so if I were you I'd try bringing it up at a Koha developer meeting on IRC. I think there's one in the next day or so: https://wiki.koha-community.org/wiki/Development_IRC_meeting_17_August_2022<br><br>Anyway, don't take anything I say as too authoritative. It's just my 2 cents (ie opinion) as someone who has been around a while. <br><br>I don't think that anyone can really guarantee that a change will be accepted, and I know that can make some developments (especially architectural ones) really hard to get off the ground. <br><br>David Cook<br>Senior Software Engineer<br>Prosentient Systems<br>Suite 7.03<br>6a Glen St<br>Milsons Point NSW 2061<br>Australia<br><br>Office: 02 9212 0899<br>Online: 02 8005 0595<br><br>-----Original Message-----<br>From: Koha-devel <koha-devel-bounces@lists.koha-community.org> On Behalf Of Thomas Klausner<br>Sent: Monday, 15 August 2022 9:57 PM<br>To: koha-devel@lists.koha-community.org<br>Subject: Re: [Koha-devel] Serving Intranet from a subpath<br><br>Hi!<br><br>On Mon, Aug 15, 2022 at 10:02:18AM +1000, dcook@prosentient.com.au wrote:<br>> I feel like we've had this conversation before but now I can't find a record of it...<br><br>Yes, we had the same problem with OPAC, and "solved" it there with a HTML-Rewriting middleware (not very stable, but good enough for now)<br><br>> I was intrigued by that "base" suggestion, but there's a few issues with it:<br><br>`base` is indeed very tricky had can have weird corner cases. But if it would have been an easy fix, I'd go with it. But as `base` is not working for our uses cases (without having to touch all links/templates) I think it's not the best option.<br><br>> Personally, I'm in favour of using "uri_for()" template methods, which <br>> are common in pretty much every web framework around today, but it <br>> would probably be a prohibitive amount of work.<br><br>A lot work, yes (though I guess that 99% can be done with a few regex, but the hard part will be finding the corner cases that did not work). <br>But the Steiermärkische Landesbibliothek is willing to do that work.<br><br>> I also wonder how it<br>> might affect some of the latest Vue.js work that Jonathan has been <br>> doing.<br><br>I don't know a lot about how that app is implemented, but usually the Vue.js app will have its own internal routing and will "only" need to know two things:<br>* where is the API the app should be talking to?<br>* where are the vue.js source files and other assets located<br><br>I also did not take a look how the Mojo API is connected with the rest and if / which paths need to be adapted there (though as Mojo provides `uri_for` I assume it will be simple)<br><br>> I'd love to get rid of "/cgi-bin/koha" one day in any case, since it's a holdover from decades past...<br><br>Yes, if we generate links via a function, we could easily get rid of `/cgi-bin/koha` in the same go :-)<br><br>> Ultimately, I think only the RM can answer this one. <br><br>And how can I get the RM to think about this issue, so we might get an answer (sorry, I'm still not that integrated into the Koha community..)<br><br>Greetings,<br>domm<br><br>-- <br>#!/usr/bin/perl https://domm.plix.at<br>for(ref bless{},just'another'perl'hacker){s-:+-$"-g&&print$_.$/}<br>_______________________________________________<br>Koha-devel mailing list<br>Koha-devel@lists.koha-community.org<br>https://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel<br>website : https://www.koha-community.org/ git : https://git.koha-community.org/ bugs : https://bugs.koha-community.org/<br><br><br><br>------------------------------<br><br>Message: 3<br>Date: Tue, 16 Aug 2022 17:41:54 +1000<br>From: <dcook@prosentient.com.au><br>To: <koha-devel@lists.koha-community.org><br>Cc: "'Kyle Hall'" <kyle@bywatersolutions.com>, "'Tomas Cohen Arazi'"<br> <tomascohen@theke.io>, "'Renvoize, Martin'"<br> <martin.renvoize@ptfs-europe.com><br>Subject: [Koha-devel] Mojolicious controllers for Koha plugins<br>Message-ID: <015f01d8b143$b921e0c0$2b65a240$@prosentient.com.au><br>Content-Type: text/plain; charset="utf-8"<br><br>Hi all,<br><br> <br><br>I was just writing a Koha plugin to do a big data export, but I realize that<br>it's probably going to timeout, because Koha plugins run under<br>Plack::App::CGIBin which buffers the entire response before it returns it to<br>Apache to return to the client browser. It's the reason Koha uses CGI<br>instead of Plack for export.pl<br><br> <br><br>While we can use Mojolicious controllers with Koha plugins when it adds REST<br>API endpoints, we can't do that for Koha plugins themselves. <br><br> <br><br>This is a topic that I've touched on before, and there are challenges when<br>it comes to Authentication and Templates, but they're solvable challenges:<br><br>https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=26791 "Build<br>Mojolicious controller replacement for export.pl"<br><br>https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=28325 "Build<br>Mojolicious controller replacement for tools-home.pl"<br><br> <br><br>We could just start by supporting "tool" and "report" with the Mojolicious<br>controllers, and that would just mean plugins-home.pl detecting that there<br>is Mojolicious support in that plugin, and then building a URL to<br>"/staff/plugins/run" instead of "/cgi-bin/koha/plugins/run.pl" for instance.<br><br> <br><br>That Mojolicious controller would really just need to check<br>authentication/authorization, which is very doable with a fairly minor<br>refactor. <br><br> <br><br>If I could get the support of just a couple other people, I'd be happy to do<br>a lot of the authoring (or testing or whatever needs to be done just to get<br>it done).<br><br> <br><br>By using Mojolicious controllers for select plugins, we'd also be able to<br>shake out any issues without causing any regressions in core Koha, and then<br>hopefully be able to start refactoring core Koha too.<br><br> <br><br>Anyways, please give it some consideration, and ask me if you have any<br>questions. <br><br> <br><br>I'll be looking more into export problems tomorrow, so I might end up going<br>a different route for the sake of time in the short-term, but I think we<br>should still be looking at shifting away from CGI and Plack::App::CGIBin due<br>to their limitations.<br><br> <br><br>David Cook<br><br>Senior Software Engineer<br><br>Prosentient Systems<br><br>Suite 7.03<br><br>6a Glen St<br><br>Milsons Point NSW 2061<br><br>Australia<br><br> <br><br>Office: 02 9212 0899<br><br>Online: 02 8005 0595<br><br> <br><br>-------------- next part --------------<br>An HTML attachment was scrubbed...<br>URL: <http://lists.koha-community.org/pipermail/koha-devel/attachments/20220816/4dd2b24b/attachment-0001.htm><br><br>------------------------------<br><br>Subject: Digest Footer<br><br>_______________________________________________<br>Koha-devel mailing list<br>Koha-devel@lists.koha-community.org<br>https://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel<br>website : https://www.koha-community.org/<br>git : https://git.koha-community.org/<br>bugs : https://bugs.koha-community.org/<br><br><br>------------------------------<br><br>End of Koha-devel Digest, Vol 201, Issue 15<br>*******************************************<br></div><br><br>NOTE: You are receiving this mail because, the Requester/Technician wanted you to get notified on this request creation.<br></body></html>