https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=15562
--- Comment #65 from David Cook <[email protected]> --- (In reply to Srdjan Jankovic from comment #64) > Well did not think of that... It should be limited by resources available, > not the application itself. It should... > I suppose I was just thinking in terms of any leaks, but hopefully it won't leak anywhere! > I'm quite sure this will never see the light of day (although I did get it > going), just too hard. However, I want to keep it alive for various reasons. > The main one is: the fact that this *is* too hard tells that we are doing > some things fundamentally wrong. Workarounds devised here (and most of it is > exactly that - workarounds) should help understanding the problems better. > Koha is being heavily optimised for the container per site scenario, but > "abstractly thinking" I don't see why we should not be able to share the > code. In a real world scenario you could imagine a cluster of small poor > schools benefiting from that. > Well, I was thinking about that from a security perspective. At the moment, we're already sharing the code, but since it's CGI it loads it up in separate processes on the fly. If we're using multiple sites with Plack managed by a single process, then we're loading the code into memory once (yay for efficiency!) but then we're also keeping all the data for all the different sites accessible in memory by the same process which could allow things to leak across if we're not careful (booo). It would be too bad if this didn't see the light of day since I imagine there would be lots of people wanting to host multiple Koha instances with the same Plack instance, but I do wonder a bit how feasible it would be, although surely people do it with other apps or URLMap wouldn't exist, yeah? Actually, I've been thinking about Tomcat a bit lately as well. I reckon it would work similarly to Plack. You define a number of URL routes and then specify the code that you want to run for each route. So you can have lots of Java apps running under the same single Tomcat instance. I don't know how it separates them so that they don't overlap of course. I suppose Tomcat might do it by virtue of Java apps being written to be run on Tomcat whereas we've been shoehorning Koha to work with Plack. > One day we will get rid of C4 and re-engineer Context, no CGI .pl... Maybe > even move to static pages and API... Then this will become obsolete. But > good to have it as a reference, until that happens. > > And thanks for your wishes :) Public transport is useful even when it's > horrible. I've been thinking for a while how nice it would be to separate the staff client and the OPAC. If I'm not mistaken, there are far fewer OPAC scripts than Staff Client scripts, so in theory writing a new OPAC would be easier than writing a new staff client. So we could build a new OPAC from the ground up that works with Plack natively. I figure library patrons should probably be the ones that demand the best performance, so why not start there, yeah? (Alternatively, if a separate OPAC is possible, it wouldn't even necessarily have to be written in Perl. Also, if we used APIs, we could use static pages with Javascript or people could access the APIs from their own websites and then we don't even have to worry about providing an OPAC - just maintaining the API.) Then maybe once the OPAC is separated out, we could work on overhauling the staff client bit by bit. That's my pie in the sky dream ;). Alas, I have too much other work to do, but it's a dream I have nonetheless... -- You are receiving this mail because: You are watching all bug changes. _______________________________________________ Koha-bugs mailing list [email protected] http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-bugs website : http://www.koha-community.org/ git : http://git.koha-community.org/ bugs : http://bugs.koha-community.org/
