[Koha-devel] Architectural goals for 3.16

[Galen Charlton]

Hi,

For discussion, here is a list of some of some things I would like to see
in 3.16.  This is not meant to be complete; please feel free to use this
thread both to comment on my goals and to suggest goals that you're
personally willing to advocate for -- and by advocate for, I mean that you
and/or the institutions who support your Koha activity are ready and
willing to take concrete steps to help implement it.  I ask that if all you
have is an idea -- no matter how good! -- but not any concrete code or
plans to have it be ready in the next few months -- please start a
different thread.

[1] Deprecation of the GRS-1 mode for Zebra.

Reason: the DOM index filter allows greater flexibility for setting up
indexing definitions.  The DOM filter also offers a path (among other
options) towards indexing non-MARC metadata.

Obstacles: the default UNIMARC indexing rules for the DOM filter need more
testing.  There is also an ongoing discussion about the desired semantics
for the Any index, which at present behaves differently with the current
DOM indexing rules as compared with GRS-1.

Upgrade considerations: in order to truly deprecate the GRS-1 filter, at
some point there will have to be a forced reindexing upon upgrade.

[2] Use DBIx::Class to deploy the database schema for new installations.

Reason: Maintaining multiple SQL schema scripts, one for each DBMS we want
to support, would be error prone.  Making edits to classes under
Koha/Schema, then using ->deploy(), offers the possibility of initializing
both MySQL and PostgreSQL databases.

DBIx::Class::Schema::Versioned could be used at as way of managing schema
updates

Obstacles: DBIx::Class doesn't automatically know anything about indexes
required for good performance; consequently, it will be necessary to write
hooks for (at least) MySQL to create the necessary indexes.

[3] Relaunch PostgreSQL support

Reason: PostgreSQL is a compelling alternative to MySQL, and now that we
have DBIx::Class in place, managing the schema for PostgreSQL is now a more
reasonable proposition.

For 3.16, I propose the following specific goals:

- Koha will be installable on a Pg database
- A staff user will be able to create or import and bib record and item
- A public catalog user will be able to search for and retrieve that item
- a reasonable number of the database-dependent tests will pass

In other words, I'm not proposing that Pg support be ready for production
by 3.16, just that it be just good enough that a developer who wants to
improve Pg support isn't starting from nothing.

[4] Upgrade the version of Bootstrap we use to 3.x.

A new major release of Bootstrap was made recently.  Unfortunately, it is
not backwards compatible with previous versions (see
http://bootply.com/bootstrap-3-migration-guide for a taste of the issues
involved).

As much as I'm personally not exactly a fan of the changes that were made
to the CSS class names, we're much better off if we bite the bullet now and
update both staff and OPAC to use the new version of Bootstrap rather than,
two years down the road, finding out that we're completely stuck on
Boostrap 2.3.

Regards,

Galen
-- 
Galen Charlton
Manager of Implementation
Equinox Software, Inc. / The Open Source Experts
email:  gmc at esilibrary.com
direct: +1 770-709-5581
cell:   +1 404-984-4366
skype:  gmcharlt
web:    http://www.esilibrary.com/
Supporting Koha and Evergreen: http://koha-community.org &
http://evergreen-ils.org
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.koha-community.org/pipermail/koha-devel/attachments/20131209/20a65e35/attachment-0001.html>