RFC for a really new stuff : sharing data worldwide
Ladies & gentlemen, We're competing more and more against providers that promote a "cloud multi-tenant LMS". Koha is a cloud application (and it is since 2000, long before cloud is born). What does "multi-tenant" mean ? It mean that you'll get access to many resources that are shared worldwide. I think that the "multi-tenancy" is a way for proprietary vendors to lock-in their customers [1]. But the idea of having a worldwide database for some informations is interesting and relevant. Proprietary vendors take care of updating this database. Open Source projects are not working centrally, so we must find another way of creating and maintaining such a database. With this thing in mind, BibLibre has decided to sponsor an intern + some internal resources for next summer dedicated to a project dedicated to sharing data between koha instances worldwide. I wrote a 1st draft of RFC and I'd like to have your feedback: http://wiki.koha-community.org/wiki/SharingDatasBetweenKohas_rfc If this project is successful, in the automn version of Koha, we may see a way to share worlwide data between all Koha libraries ! [1] if you're a proprietary vendor and are reading this: I don't mean it's the only reason for multi-tenancy. -- Paul Poulain, Associé-gérant / co-owner BibLibre, Services en logiciels libres pour les bibliothèques BibLibre, Open Source software and services for libraries
"Multi-tenant" is certainly a vague term. Koha via Debian packages is already multi-tenant at the code level. Personally I don't know why someone would promote "multi-tenant" as something desirable in a lot of contexts, but I see that you're referring to it in the sense of sharing data. That's cool. One of my first tasks at Prosentient, back when I was an intern, was to create a SQL report database that was shared amongst all our Koha customers. It was early in my programmer days, so it's rather awful, but I think it may have been useful for a time. Each different Koha database user had read access to a central database schema of reports, and they could clone those reports into their local Koha database. I think Chris Cormack, Liz Rea, and I were actually talking about the SQL Report Library on the wiki and how it's quite unwieldy... and Liz was saying how it would be great if you could upvote and downvote reports. I think that's something that you mention in your RFC (e.g. "good data" vs "bad data"). I think that's a great idea. Vendors, serial (publishing) patterns... yeah I could see that being useful too. "Subscriptions" per se maybe not so much as those are specific to vendor-client contracts. But yeah I think overall it's a good idea. David Cook Systems Librarian Prosentient Systems 72/330 Wattle St, Ultimo, NSW 2007
-----Original Message----- From: koha-devel-bounces@lists.koha-community.org [mailto:koha-devel- bounces@lists.koha-community.org] On Behalf Of Paul Poulain Sent: Thursday, 21 January 2016 1:19 AM To: koha-devel@lists.koha-community.org Subject: [Koha-devel] RFC for a really new stuff : sharing data worldwide
Ladies & gentlemen,
We're competing more and more against providers that promote a "cloud multi-tenant LMS". Koha is a cloud application (and it is since 2000, long before cloud is born). What does "multi-tenant" mean ? It mean that you'll get access to many resources that are shared worldwide.
I think that the "multi-tenancy" is a way for proprietary vendors to lock-in their customers [1]. But the idea of having a worldwide database for some informations is interesting and relevant. Proprietary vendors take care of updating this database. Open Source projects are not working centrally, so we must find another way of creating and maintaining such a database.
With this thing in mind, BibLibre has decided to sponsor an intern + some internal resources for next summer dedicated to a project dedicated to sharing data between koha instances worldwide.
I wrote a 1st draft of RFC and I'd like to have your feedback: http://wiki.koha-community.org/wiki/SharingDatasBetweenKohas_rfc
If this project is successful, in the automn version of Koha, we may see a way to share worlwide data between all Koha libraries !
[1] if you're a proprietary vendor and are reading this: I don't mean it's the only reason for multi-tenancy.
-- Paul Poulain, Associé-gérant / co-owner BibLibre, Services en logiciels libres pour les bibliothèques BibLibre, Open Source software and services for libraries
_______________________________________________ Koha-devel mailing list Koha-devel@lists.koha-community.org http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel website : http://www.koha-community.org/ git : http://git.koha- community.org/ bugs : http://bugs.koha-community.org/
About sharing data, it may be an Koha-independent project, but a linked-one also, there is the issue of the books cover images. There are now coming from various providers (Google, Amazon, etc.). It would be great to have an images storage server which could replace the one integrated in Koha (local cover images). This would allow libraries to share scanning work. OpenLibrary was supposed to be that exactly.
Hi Paul, I have this idea (share reports) in mind for a while. The main point was to keep up-to-date the reports listed on the wiki page (https://wiki.koha-community.org/wiki/SQL_Reports_Library). IMO one important thing is to cover each report with tests, to confirm they still pass from one version to another. It will also permit to have a versioning of them: "this report is valid from version 3.XX to version 3.YY" For a another use, have a look at the commit message of the first patch of bug 14100: Generic solution for language overlay - Item types: N/ Implement a webservice to centralize all the translations and give the ability to sync the item types/authorised values description with the rest of the world (push and pull). It would be good to keep that in mind for a future implementation. 2016-01-20 14:18 GMT+00:00 Paul Poulain <paul.poulain@biblibre.com>:
Ladies & gentlemen,
We're competing more and more against providers that promote a "cloud multi-tenant LMS". Koha is a cloud application (and it is since 2000, long before cloud is born). What does "multi-tenant" mean ? It mean that you'll get access to many resources that are shared worldwide.
I think that the "multi-tenancy" is a way for proprietary vendors to lock-in their customers [1]. But the idea of having a worldwide database for some informations is interesting and relevant. Proprietary vendors take care of updating this database. Open Source projects are not working centrally, so we must find another way of creating and maintaining such a database.
With this thing in mind, BibLibre has decided to sponsor an intern + some internal resources for next summer dedicated to a project dedicated to sharing data between koha instances worldwide.
I wrote a 1st draft of RFC and I'd like to have your feedback: http://wiki.koha-community.org/wiki/SharingDatasBetweenKohas_rfc
If this project is successful, in the automn version of Koha, we may see a way to share worlwide data between all Koha libraries !
[1] if you're a proprietary vendor and are reading this: I don't mean it's the only reason for multi-tenancy.
-- Paul Poulain, Associé-gérant / co-owner BibLibre, Services en logiciels libres pour les bibliothèques BibLibre, Open Source software and services for libraries
_______________________________________________ Koha-devel mailing list Koha-devel@lists.koha-community.org http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel website : http://www.koha-community.org/ git : http://git.koha-community.org/ bugs : http://bugs.koha-community.org/
The various Koha translations could also be placed under the umbrella of this "Data Sharing" project. Rather than embedding translation files (.po files) into Koha base code, they could be available online and retrieved from Koha "Data Sharing" server (KDSS), and then installed on the fly when required. The KDSS itself could be synchronized automatically with the Pootle server.
The idea was to manage po files using git subtree: http://lists.koha-community.org/pipermail/koha-devel/2015-March/041293.html 2016-02-01 11:35 GMT+00:00 Frédéric Demians <frederic@tamil.fr>:
The various Koha translations could also be placed under the umbrella of this "Data Sharing" project. Rather than embedding translation files (.po files) into Koha base code, they could be available online and retrieved from Koha "Data Sharing" server (KDSS), and then installed on the fly when required. The KDSS itself could be synchronized automatically with the Pootle server. _______________________________________________ Koha-devel mailing list Koha-devel@lists.koha-community.org http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel website : http://www.koha-community.org/ git : http://git.koha-community.org/ bugs : http://bugs.koha-community.org/
The idea was to manage po files using git subtree: http://lists.koha-community.org/pipermail/koha-devel/2015-March/041293.html
See that also: https://wiki.koha-community.org/wiki/Git_Splitting_and_Shrinking Do we really need a Git repo for translation files since the authoring of translated strings is managed outside Git in Pootle?
Hi, On Mon, Feb 1, 2016 at 7:27 AM, Frédéric Demians <frederic@tamil.fr> wrote:
Do we really need a Git repo for translation files since the authoring of translated strings is managed outside Git in Pootle?
I think there's some value in continuing to have one: - in the (of course unlikely) event that the Pootle server completely fails and cannot be restored, such a repository would serve as a backup of last resort. Likewise for the (even more unlikely) event that somebody does major vandalism on a translation, as Pootle itself does not have version control. - the repository would enable reproducing a package or tarball, which in turn would be useful for tracking down the occasional bug that stems from an issue with one of the PO files. Regards, Galen -- Galen Charlton Infrastructure and Added Services Manager Equinox Software, Inc. / The Open Source Experts email: gmc@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
What I have in mind is a mechanism which would allow Koha users to go in Administration, and request a specific language for their installed Koha version. For example, I run Koha 3.22.1. I go in Admin > WUI Language. I select a language. I see a list of .po versions for this combinaison (Koha version / language) ordered by reverse date of publication. I choose one of them, and install it. The .po files are downloaded. Templates are recreated. With this mechanism, if the Koha Data Sharing Server (KDSS) is synchronized once a day with Pootle, I can modify my language translation on Pootle, and 24 hours later download and install the last language version. The translation files are not anymore in the tarball. It looks like that: Pootle | <synchro> | KDSS | <Update PO> | <Koha Servers> The Pootle server is used by translators. It can't serve directly translatations to Koha servers for performance reasons. A proxy repository is required (KDSS). Once a day, the language repository can be updated with Pootle last translation files. If those files were placed in a Git repository, we would have also performance issues because the branch containing the requested version by a Koha server would have to be checked out. It's also impossible to serve two simultaneous requests for different Koha versions. I would rather have a file system arborescence storing zipped .po files per Koha version / language / date of publication. Or using a data store like MongoDB GridFS... But enough idle talk...
participants (5)
-
David Cook -
Frédéric Demians -
Galen Charlton -
Jonathan Druart -
Paul Poulain