I haven’t worked with Plack or Mojolicious, but I have worked with mod_perl and Catalyst, and I think moving towards persistence and a web framework are both good ideas. Ultimately, I think we need to do *something*. I don’t think the status quo is really good enough. I think we need to draw a line in the sand at some point and denote a major shift in how we do things. Why don’t we re-make the OPAC using Mojolicious and Plack? The OPAC is much much smaller in terms of code and functionality than the Staff Client, so probably much more achievable than a re-write of the Staff Client. We could flesh out the HTTP API more and actually have it use that instead of the internal API. That then opens up the possibility of other front-ends for Koha as well. After that, we could look at making the backend more (micro) service oriented. By that, I mean that we could de-couple the modules by focusing on making a robust API, which allows us to swap modules in and out without affecting the whole rest of the system. If we improve APIs for adding/modifying/deleting records, there’s no reason why a person couldn’t catalogue using anything (a Koha cataloguer, MarcEdit, a third-party tool, OCLC, the CLI, OAI-PMH stream, etc). If done right, that could also allow us to start moving towards other metadata formats. If we abstracted search away more, we wouldn’t have as much difficulty adding ElasticSearch (or any other search engine); we’d only have to focus on the search API. Of course, we’d also need a query parser for that to work well… I suppose I’m a dreamer when it comes to the backend :p. Going back to what Tomas was saying… I think we should start thinking about Koha as a Plack app rather than Koha with optional Plack. David Cook Systems Librarian Prosentient Systems 72/330 Wattle St Ultimo, NSW 2007 Office: 02 9212 0899 Direct: 02 8005 0595 From: koha-devel-bounces@lists.koha-community.org [mailto:koha-devel-bounces@lists.koha-community.org] On Behalf Of Tomas Cohen Arazi Sent: Wednesday, 4 May 2016 11:23 PM To: Julian Maurice <julian.maurice@biblibre.com> Cc: koha-devel <koha-devel@lists.koha-community.org> Subject: Re: [Koha-devel] Time to think Plack? 2016-05-04 10:07 GMT-03:00 Julian Maurice <julian.maurice@biblibre.com <mailto:julian.maurice@biblibre.com> >: Hi Tomas, As I haven't worked much with Plack, I am not sure to understand what you mean by "thinking of Koha as a Plack app". Do you mean rewrite Koha so that Plack::App::CGIBin is not needed to make it work under Plack ? I'm not sure. A while back I recall devs started to do their daily dev tasks with plack enabled to we could find all bugs, so we reached a good level of compatibility for running inside plack. I think we moved forward, a lot. At a point where users can just enable Plack and enjoy it with a single CLI command. But if you look closer, we are still putting several pieces together, that could, at some point be avoided to simplify our stack and workflows. Not sure how to do it, just rising the question. How is it related to the API implementation with Mojolicious ? I believe Mojolicious apps can be turned into Plack apps quite easily. The point of the REST api using Mojolicious was that it is a separate set of tools, that doesn't interfere with the old-loved Koha. If it gains momentum and evolves, we could make several UI pieces rely on it. And of course, we shouldn't run it on a CGI emulator if it can run natively as a Plack app. The main problem with it is that it is not integrated into the packages, so users cannot take advantage of it right now. I forgot to fill a bug about it. Are you suggesting we should extend the use of Mojolicious to all parts of Koha ? There's no consensus about Mojolicious actually. I'd say leave it for the REST api, and extend it so it can make sense to use it for the UI, eventually deprecating some .pl scripts. In a baby steps approach, as we like. My post was about to start talking about what we expect in a mid term about the plack integration and the rocks that block that road. To start with, the current packages integration relies on the new apache's mod_proxy's UDS support, which seems really buggy regarding the way it handles SCRIPT_NAME and PATH_INFO, thus making our Plack use problematic at some point. If you point NGINX into our starman socket, you will see how it has to be done, working properly. This specific issue might led to a new thread about supporting different HTTP servers on our packages, but lets start with 'what we want about the plack integration for the short term, and what is holding devs from using plack, daily'. Regards On 04/05/2016 14:39, Tomas Cohen Arazi wrote:

Hi everyone, I just wanted to raise some questions, that might be worth thinking about at the KohaCon16 hackfest, or just here.

Koha has been a CGI app for ages. And we slowly made it work under Plack to gain performance. We did so, by running it inside a CGI emulation context (i.e. CGI::Emulate::PSGI [1]). We even wired all stuff so packages can take advantage of Plack out of the box (just not enabled by default, that'd be a next future step).

We then introduced a Mojolicious implementation of (a beggining of) a REST API.

Is it time to start thinking of Koha as a Plack app and focus on that?

[1] Through Plack::App::CGIBin actually.

-- Tomás Cohen Arazi Theke Solutions (http://theke.io <http://theke.io/>) ✆ +54 9351 3513384 GPG: B2F3C15F

_______________________________________________ Koha-devel mailing list Koha-devel@lists.koha-community.org <mailto: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/

-- Julian Maurice <julian.maurice@biblibre.com <mailto:julian.maurice@biblibre.com> > BibLibre _______________________________________________ Koha-devel mailing list Koha-devel@lists.koha-community.org <mailto: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/ -- Tomás Cohen Arazi Theke Solutions (http://theke.io <http://theke.io/> ) ✆ +54 9351 3513384 GPG: B2F3C15F