<p dir="ltr">Thanks for the overview Jonathan! I know I for one have the react discussion as a top priority for the jacket.</p>
<p dir="ltr">Kyle</p>
<p dir="ltr">Sent from my phone. Please excuse my brevity.</p>
<div class="gmail_extra"><br><div class="gmail_quote">On Oct 8, 2016 2:20 PM, "Jonathan Druart" <<a href="mailto:jonathan.druart@bugs.koha-community.org">jonathan.druart@bugs.koha-community.org</a>> wrote:<br type="attribution"><blockquote class="quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hello librarians and developers,<br>
<br>
I send a "What's on in Koha devel" email to koha-devel list each<br>
month. But this one is a bit special as I will focus on the different<br>
subjects you may heard of if you attend the hackfest in Marseille next<br>
week.<br>
It can be helpful for both librarians and developers!<br>
<br>
A lot of things are going on in the Koha ecosystem so it might be hard<br>
to follow all the discussions or to jump into one.<br>
<br>
So my attempted goal here is to compile the topics currently "à la<br>
mode" for Koha developers.<br>
In this email I will go a bit more into details than usual, to let you<br>
the opportunity to better understand the themes and to ask questions<br>
next week if you want to know more. I hope it will help you to choose<br>
the subject you want to be involved in during the hackfest.<br>
<br>
= Sandboxes =<br>
<br>
Sandboxes have been developed with the aim to help people without any<br>
technical skills to test patches submitted on the Koha bugtracker.<br>
You will find all the information you want on the dedicated wiki page<br>
<a href="https://wiki.koha-community.org/wiki/Sandboxes" rel="noreferrer" target="_blank">https://wiki.koha-community.<wbr>org/wiki/Sandboxes</a><br>
<br>
= Refactoring =<br>
During the last 3 (more?) years we have integrated DBIx::Class (a Perl<br>
ORM, Object-Relationnal Mapping) into Koha, for several (sometimes<br>
disputed) reasons.<br>
To take advantage of it, we are using it as much as possible through a<br>
home-made object module called Koha::Object.<br>
For the last year, a lot of legacy code has been rewritten and moved<br>
out of the C4 namespace to the new Koha namespace. For instance<br>
Koha::Virtualshelves replaced C4::VirtualShelves::Page (bug 14544),<br>
Koha::Libraries replaces C4::Branch (bug 15293).<br>
At the moment, the job focusses on moving the legacy authorised values<br>
from the C4::Koha module to Koha::AuthorisedValues (bug 15799) and the<br>
patrons/borrowers/users/<wbr>members code from C4::Members to Koha::Patrons<br>
(bug 16846).<br>
For an overview of this refactoring work, please have a look at bug<br>
15449 and its scary dependency graph:<br>
<a href="https://bugs.koha-community.org/bugzilla3/showdependencygraph.cgi?id=15449" rel="noreferrer" target="_blank">https://bugs.koha-community.<wbr>org/bugzilla3/<wbr>showdependencygraph.cgi?id=<wbr>15449</a><br>
<br>
Another refactoring work is about moving the biblioitems.marcxml<br>
content out of the biblioitems table. The idea is to create another<br>
table (biblio_metadata) to add the ability to store a record in<br>
different formats. The direct and major addition of this move would be<br>
to bring performance speed. See the comment 1 of bug 17196 for more<br>
information.<br>
<br>
= Speed improvements =<br>
<br>
During the last 2 releases, we have made a lot of speed improvements.<br>
That has been achieve with the consolidation and the stabilisation of<br>
our caching system and plack integration.<br>
If you are running a recent version of Koha (3.22, 16.05 or later) you<br>
should set them up correctly to fully enjoy the improvement. To be<br>
fair I must say that we have had to concentrate our efforts on these<br>
points because of our previous technical decisions (mainly related to<br>
DBIx::Class).<br>
Two main playgrounds: Plack and Memcached, that I will explain now.<br>
<br>
== Plack ==<br>
I bet you already have heard of Plack, because Koha developers have<br>
been talking about it for ages.<br>
Basically it is just an interface between the web server (Apache,<br>
starman, etc.) and the perl application (Koha).<br>
When a user hits the a Koha url, a lot of files (Perl modules) are<br>
compiled. In CGI mode, this compilation step is done for every<br>
request. Using Plack they are compiled only once. The code will be put<br>
in RAM and other requests won't need to process all the modules again.<br>
It is an advantage since we are using DBIx::Class more and more and<br>
its schema is heavy to load. With Plack it is only loaded once.<br>
Koha is now considered as stable under Plack for the last versions of<br>
Koha, so you must use it.<br>
To know about known bugs, you can follow bug 7172 which gather Plack<br>
related known bugs together. At this time there is only one patch not<br>
yet pushed, bug 17392 (ping QAer!).<br>
<br>
Note that a timeout issue seems related to Plack and is not yet resolved, see:<br>
Bug 16714 - Unexpected logout with "IP address change" (with<br>
SessionRestrictionByIP set)<br>
<br>
== Caching system ==<br>
The way we are caching "stuffs" in Koha has really been improved<br>
recently and will continue to!<br>
Important steps have been done in this area.<br>
We are using Memcached - a memory caching system - to store big bunch<br>
of data that we do not want to recalculate or retrieve from the<br>
database everytime.<br>
For instance:<br>
 - the sysprefs. A lot of them are retrieved from the database for each request<br>
 - the biblio frameworks<br>
 - the holidays<br>
 - ... a lot of other things could/will be cached!<br>
<br>
A big step has been done when we decided to introduce a 2-level<br>
caching mechanism (bug 16044): we have now a in-memory L1 cache (flush<br>
at every request) and a L2 cache (Memcached).<br>
To understand how this mechanisms are useful, imagine a simple<br>
scenario: launch a search which will return 20 results.<br>
For each result we need to know the MARC bibliographic framework of<br>
the record. Say they are all using the default frameworkcode. Without<br>
any caching mechanism, we retrieved from the database the whole<br>
structure, 20 times, once per result.<br>
With our new caching mechanism, the information for the default MARC<br>
bibliographic framework will be retrieved on the first request, then<br>
put in both L1 and L2 cache. The 19 other results will retrieve it<br>
from the L1 cache.<br>
If the same or another user does a search, the framework info will be<br>
retrieved from the L2 cache for the first result, and the L1 cache<br>
will be populated. The other results will retrieve it from the L1<br>
cache.<br>
Not sure this is clear, but catch me if you need more details :)<br>
<br>
All of that to say that if you are a developer, there are 3 other bugs<br>
with ideas to improve again the caching mechanism. They are all of<br>
them in discussion:<br>
Bug 16140 - Only clear L1 cache when needed<br>
Bug 16079 - Retrieving system preferences from database via DBIx is<br>
not fast enough<br>
Bug 15341 - Performance - Retrieve all sysprefs at once<br>
<br>
One which would be nice to have is:<br>
Bug 17261 - Add memcached configuration info to <a href="http://about.pl" rel="noreferrer" target="_blank">about.pl</a><br>
It will permit to display the memcached configuration in the about page.<br>
<br>
<br>
= MySQL 5.7 compatibility =<br>
If you are interested in using Koha with MySQL 5.7 (the default<br>
version for the last Ubuntu 16.04), you should take a look at bug<br>
17258 and its dependencies.<br>
Koha is not ready at all for the new default sql_mode configuration of<br>
this version of MySQL (STRICT_TRANS_TABLES).<br>
<br>
= Security issues =<br>
A lot of security issues (CSRF and XSS) have been fixed for the last 4<br>
months, and almost all of these fixes have been backported to stable<br>
releases.<br>
They are all reported under the 2 following omnibus:<br>
Bug 17096 - [OMNIBUS] CSRF protections<br>
Bug 14568 - [OMNIBUS] XSS in Staff Client<br>
Only one known bug is waiting to be QAed (but 17365).<br>
<br>
= Elastic search =<br>
There are no big new features pushed since the first big push.<br>
But a few bug fixes and enhancement are waiting to be QAed. You can<br>
find them on the dependency graph of bug 12478.<br>
Note that there are 2 known bugs, without patches:<br>
<br>
Bug 16660 - Elasticsearch broken if OpacSuppression is activated<br>
Bug 17373 - Elasticsearch - Authority mappings are not defined for UNIMARC<br>
Are there some UNIMARC users around? :)<br>
<br>
= RESTful API =<br>
Tons of patches have been submitted on bugzilla, but only few got<br>
attention from signoffers.<br>
If you are interested in testing of them, search for "rest api".<br>
<br>
= ReactJS =<br>
React is a JS library aimed to easier DOM manipulations.<br>
This topic is a recurrent one and developers involved in this<br>
discussion will be present at the hackfest.<br>
They should organise a discussion to reach a consensus once and for<br>
all. If accepted, it would be good to define guidelines and write<br>
complete examples.<br>
<br>
= Koha plugin system =<br>
It seems that people are curious about our plugin system.<br>
It would be good to revive the discussion on new and more powerful<br>
plugin system.<br>
See the discussion on the koha-devel list at<br>
<a href="http://lists.koha-community.org/pipermail/koha-devel/2016-May/042673.html" rel="noreferrer" target="_blank">http://lists.koha-community.<wbr>org/pipermail/koha-devel/2016-<wbr>May/042673.html</a><br>
<br>
= Transactions & exceptions =<br>
It would be good to see some developers organise a brainstorming<br>
session on the different topics that Tomas raised on his email to<br>
koha-devel a few weeks ago.<br>
<a href="http://lists.koha-community.org/pipermail/koha-devel/2016-September/043032.html" rel="noreferrer" target="_blank">http://lists.koha-community.<wbr>org/pipermail/koha-devel/2016-<wbr>September/043032.html</a><br>
<br>
= Mana =<br>
Paul presented us Mana<br>
(<a href="https://lists.katipo.co.nz/pipermail/koha/2016-July/045739.html" rel="noreferrer" target="_blank">https://lists.katipo.co.nz/<wbr>pipermail/koha/2016-July/<wbr>045739.html</a>) at<br>
the beginning of July.<br>
Morgan finished her internship and will be there are the hackfest to<br>
show us what she developed.<br>
Testers and QAers would certainly be welcomed to test and review this feature.<br>
<br>
= Hea =<br>
Hea is a website (<a href="http://hea.koha-community.org" rel="noreferrer" target="_blank">http://hea.koha-community.org</a><wbr>) collecting usage<br>
statistics from different Koha installations around the world.<br>
This feature is not enabled by default but is very useful for<br>
developers and other people loving statistics (so librarians isn't<br>
it?).<br>
If it is not done yet, you should enable this feature to join the 496<br>
libraries already registered!<br>
One enhancement is developed and waiting for testers:<br>
14608 - HEA : add possibility of sharing usage statistics in<br>
Administration page and Web installer<br>
<br>
Hope to see you ready to fix, translate, test or QA patches (and drink<br>
beers when everything is done) this week!<br>
<br>
Cheers,<br>
Jonathan<br>
______________________________<wbr>_________________<br>
Koha-devel mailing list<br>
<a href="mailto:Koha-devel@lists.koha-community.org">Koha-devel@lists.koha-<wbr>community.org</a><br>
<a href="http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel" rel="noreferrer" target="_blank">http://lists.koha-community.<wbr>org/cgi-bin/mailman/listinfo/<wbr>koha-devel</a><br>
website : <a href="http://www.koha-community.org/" rel="noreferrer" target="_blank">http://www.koha-community.org/</a><br>
git : <a href="http://git.koha-community.org/" rel="noreferrer" target="_blank">http://git.koha-community.org/</a><br>
bugs : <a href="http://bugs.koha-community.org/" rel="noreferrer" target="_blank">http://bugs.koha-community.<wbr>org/</a></blockquote></div><br></div>