[Koha-bugs] [Bug 15562] Make Koha more suitable for shared hosting with plack

[bugzilla-daemon at bugs.koha-community.org]

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=15562

--- Comment #65 from David Cook <dcook at prosentient.com.au> ---
(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.