[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 #67 from David Cook <dcook at prosentient.com.au> ---
(In reply to Srdjan Jankovic from comment #66)
> That was exactly my point with Context. There should be no references to
> *anything* external (db, cache etc handles) outside Context. Now because we
> are still in this CGI frame of mind, we have all this horrible singletons.
> Once we are able to instantiate contexts and keep them in app containers,
> and pass them to request handlers we will be safe.

Agreed!

Even if these patches don't go in, I figure it's worthwhile getting rid of the
singletons even for the sake of testing and flexibility. 

(On an unrelated note, I just noticed Starman can listen on Unix sockets, and I
recall Nginx being able to reverse proxy to Unix sockets. Apparently Apache
2.4.7+ can as well. I wonder what kind of performance boost that would give.
Actually, say the OPAC was separate but still server-side and using an API,
calls to a Koha API over a Unix socket would probably be rather fast. I wonder
if you could have a single Koha API process which needs the most resources and
then have separate smaller processes for the OPAC (and perhaps staff client).
Or not even have an OPAC and just let other services access the API. Although I
suppose as a project we'd want to have a default OPAC app for an all-in-one
solution. I suppose the architecture depends on the scale needed for Koha too.
Probably easier to scale up by having lighter clients connecting to APIs and
have it all service based. But then also more complicated to set up and
maintain. Actually, I was also pondering having a single persistent Koha API
process and then serving the OPAC (and staff client) via CGI. If they're
lightweight and most of the heavy lifting is done by the API, maybe that would
be a reasonable way to have a large multitenant system. But maybe that just
sounds better in theory than it would be in practice. For things like record
uploads, that's probably not feasible and would just involve double-handling
and double-parsing. Oh well. I'll stop rambling now...)

-- 
You are receiving this mail because:
You are watching all bug changes.