We want to take this opportunity to congratulate Biblibre for initiating the search engine change with which we are identified and in which we would like to collaborate, due to the important problem on the facets. We believe that it is time to examine some aspects of the project, with no intention of offending any member of the community in doing so. In Xercode, despite being a new company, some of our members have been working on the project since 2007, when we first came into contact with PERL. All of our present developers have been working on PHP and JAVA projects. Since then, we have been conscious that the structure of KOHA is unlike any other major project we have worked on previously. In our opinion, it has become necessary to upgrade technologies employed in the project making KOHA more competitive with similar software. We believe that is urgent to use a framework like DANCER, SOLR as an index engine (our main problem with clients), increase performance, ... We believe, however, that this will not completely resolve our present situation due to the fact that the project structure is not sufficiently defined. A good example is the propose of search engine change, a current point of conflict. We have traditionally followed an Object Oriented Metodology (working with interfaces and abstract classes). By doing this we would achieve an abstraction of the search engine and the result of using a method, for example “engineSearch”, would be the same with indifference to use SOLR or ZEBRA and the majority of problems that we are currently facing in the community (principally the integration of the diverse developments by each member) can be easily resolved. Applying this philosophy to .pl files would make them more concise and more easily understood. DRUPAL and OTRS (PERL) are good examples composed by a kernel and specific modules. Considering all of this, this is a perfect moment for reflexion due to the fact that these points may affect the scalability and evolution of KOHA. Regards, * Miguel Angel Calvo Lázaro* *Dirección de Soluciones* miguel.calvo@xercode.es Telf. 653 038 238 Rosalía de Castro, 53 4º C 15895 Milladoiro - Ames (A Coruña) Telf. 881 975 576 www.xercode.es info@xercode.es La información contenida en este mensaje y sus posibles documentos adjuntos es privada y confidencial y está dirigida únicamente a su destinatario/a. Si usted no es el/la destinatario/a original de este mensaje, por favor elimínelo. La distribución o copia de este mensaje no está autorizada.
hello, On Fri, Nov 12, 2010 at 06:06:30PM +0100, Miguel Angel Calvo Lázaro wrote:
We believe that is urgent to use a framework like DANCER, SOLR as an index engine (our main problem with clients), increase performance, ...
Dancer would really help to drop lot of code from koha. Plus I really would like to see koha based on external libs. Some of them are: http://search.cpan.org/~flora/MooseX-Declare-0.34/lib/MooseX/Declare.pm http://search.cpan.org/~frew/DBIx-Class-0.08124/lib/DBIx/Class.pm http://git.tamil.fr/?p=marc-moose;a=summary http://search.cpan.org/~sartak/Template-Declare-0.43/lib/Template/Declare.pm https://github.com/eiro/MARC-Template regards -- Marc Chantreux BibLibre, expert en logiciels libres pour l'info-doc http://biblibre.com
Hello, Miguel. You state well the necessity of adopting these sorts of strategies to promote the long term viability of Koha. Without architectural clarity, the ability to add and refine features is growing increasingly difficult without stepping on other people's work and introducing action-at-a-distance bugs. Working toward a solution to this dilemma is exactly the purpose of having a technical committee^H^H^H^H^H^H^H meetings to hash these issues out and try to develop a consensus on which tools and patterns would best suit Koha, then draw a road map describing incremental steps developers can take in order to get from point A to point B. I have a few high-level ideas toward this end: * start separating out the monolithic C4 modules into Model and Controller modules, cleaning up circular dependencies as needed. * move most of the contents of .pl files into the View modules. * switch to more flexible template system, like TT. * split out C4::Context into "user" context for authorization, "schema" context for data sources, "environment" context for CGI vs. CLI vs. PSGI * centralize database access calls, either through an ORM or through a customized layer on top of DBI. I think the specific tools applied are less critical than the underlying principles which any number of those tools could facilitate. Cheers, Clay 2010/11/12 Miguel Angel Calvo Lázaro <mac.xercode@gmail.com>
We want to take this opportunity to congratulate Biblibre for initiating the search engine change with which we are identified and in which we would like to collaborate, due to the important problem on the facets.
We believe that it is time to examine some aspects of the project, with no intention of offending any member of the community in doing so.
In Xercode, despite being a new company, some of our members have been working on the project since 2007, when we first came into contact with PERL. All of our present developers have been working on PHP and JAVA projects. Since then, we have been conscious that the structure of KOHA is unlike any other major project we have worked on previously.
In our opinion, it has become necessary to upgrade technologies employed in the project making KOHA more competitive with similar software.
We believe that is urgent to use a framework like DANCER, SOLR as an index engine (our main problem with clients), increase performance, ... We believe, however, that this will not completely resolve our present situation due to the fact that the project structure is not sufficiently defined.
A good example is the propose of search engine change, a current point of conflict. We have traditionally followed an Object Oriented Metodology (working with interfaces and abstract classes). By doing this we would achieve an abstraction of the search engine and the result of using a method, for example “engineSearch”, would be the same with indifference to use SOLR or ZEBRA and the majority of problems that we are currently facing in the community (principally the integration of the diverse developments by each member) can be easily resolved.
Applying this philosophy to .pl files would make them more concise and more easily understood. DRUPAL and OTRS (PERL) are good examples composed by a kernel and specific modules.
Considering all of this, this is a perfect moment for reflexion due to the fact that these points may affect the scalability and evolution of KOHA.
Regards,
* Miguel Angel Calvo Lázaro*
*Dirección de Soluciones* miguel.calvo@xercode.es Telf. 653 038 238
Rosalía de Castro, 53 4º C 15895 Milladoiro - Ames (A Coruña) Telf. 881 975 576 www.xercode.es info@xercode.es
La información contenida en este mensaje y sus posibles documentos adjuntos es privada y confidencial y está dirigida únicamente a su destinatario/a. Si usted no es el/la destinatario/a original de este mensaje, por favor elimínelo. La distribución o copia de este mensaje no está autorizada.
_______________________________________________ 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/
Hie, I agree with the point that abstraction is necessary in modern softwares. But can Perl achieve this goal ? I'm used to Java with MVC, patterns and object/database mapping. We could imagine a migration step by step from Perl to Java since Perl compiler is integrated into JVM. Regards, 2010/11/12 Clay Fouts <cfouts@liblime.com>
Hello, Miguel.
You state well the necessity of adopting these sorts of strategies to promote the long term viability of Koha. Without architectural clarity, the ability to add and refine features is growing increasingly difficult without stepping on other people's work and introducing action-at-a-distance bugs. Working toward a solution to this dilemma is exactly the purpose of having a technical committee^H^H^H^H^H^H^H meetings to hash these issues out and try to develop a consensus on which tools and patterns would best suit Koha, then draw a road map describing incremental steps developers can take in order to get from point A to point B.
I have a few high-level ideas toward this end: * start separating out the monolithic C4 modules into Model and Controller modules, cleaning up circular dependencies as needed. * move most of the contents of .pl files into the View modules. * switch to more flexible template system, like TT. * split out C4::Context into "user" context for authorization, "schema" context for data sources, "environment" context for CGI vs. CLI vs. PSGI * centralize database access calls, either through an ORM or through a customized layer on top of DBI.
I think the specific tools applied are less critical than the underlying principles which any number of those tools could facilitate.
Cheers, Clay
-- Fridolyn SOMERS ICT engineer PROGILONE - Lyon - France fridolyn.somers@gmail.com
Le 15/11/2010 10:05, Fridolyn SOMERS a écrit :
Hie,
I agree with the point that abstraction is necessary in modern softwares. But can Perl achieve this goal ? I'm used to Java with MVC, patterns and object/database mapping.
We could imagine a migration step by step from Perl to Java since Perl compiler is integrated into JVM. Yikes ! I won't say no without reading more arguments, but you'll have to be VERY persuasive about what we would win and how such a move could be done !
(and yes, I think Perl can achieve the MVC goal) -- Paul POULAIN http://www.biblibre.com Expert en Logiciels Libres pour l'info-doc Tel : (33) 4 91 81 35 08
Hi, On Mon, Nov 15, 2010 at 4:12 AM, Paul Poulain <paul.poulain@biblibre.com> wrote:
Le 15/11/2010 10:05, Fridolyn SOMERS a écrit :
I'm used to Java with MVC, patterns and object/database mapping.
We could imagine a migration step by step from Perl to Java since Perl compiler is integrated into JVM. Yikes !
Indeed, yikes! :) Perl is capable of supporting MVC and ORMs. Rewriting Koha in Java, no matter how carefully planned, would be a time consuming process, and the result would almost certainly be worse than simply writing a new Java-based ILS from scratch. That is not to say, however, that there couldn't be some interesting experiments to try getting Koha and Java code to interoperate, and if/when Koha adopts Perl 6, Parrot might provide a bridge as well. Regards, Galen -- Galen Charlton gmcharlt@gmail.com
Folks since this says it's about "reflexion", let me add my voice here. I have to confess I don't know much about the internals of koha, and I have not used solr. I understand that solr is a full-text indexer. I think to use this best, it would be advisable to first create a set of static web pages, one for each item in the catalog, and then use solr on this set. Libraries can in this way expose their catalog to the web (and have all the visibility benefits from that) and use the pages for a second search engine via solr. Such an approach to solr indexing could be an optional add on that would not conflict with the current internals of koha. I would not wish to see solr as the primary engine since zebra does so many things that are specific to the library world. Cheers, Thomas Krichel http://openlib.org/home/krichel http://authorclaim.org/profile/pkr1 skype: thomaskrichel
Le 15/11/2010 21:11, Thomas Krichel a écrit :
I would not wish to see solr as the primary engine since zebra does so many things that are specific to the library world.
Could you tell us which specific things you're thinking of ? Because, until now, except for the z3950 server, I don't see anything solR can't handle. thanks for your inputs -- Paul POULAIN http://www.biblibre.com Expert en Logiciels Libres pour l'info-doc Tel : (33) 4 91 81 35 08
Paul Poulain writes
Le 15/11/2010 21:11, Thomas Krichel a écrit :
I would not wish to see solr as the primary engine since zebra does so many things that are specific to the library world.
Could you tell us which specific things you're thinking of ? Because, until now, except for the z3950 server, I don't see anything solR can't handle.
ok. I still think that the Z39.50 is important enough but I may be wrong on that. But more importantly, I think that koha ils systems will do better to globally expose all contents to the web, and free ride on Google at alii indexing, than setting up more search features internally. Cheers, Thomas Krichel http://openlib.org/home/krichel http://authorclaim.org/profile/pkr1 skype: thomaskrichel
Le 15/11/2010 21:59, Thomas Krichel a écrit :
Could you tell us which specific things you're thinking of ? Because, until now, except for the z3950 server, I don't see anything solR can't handle.
ok. I still think that the Z39.50 is important enough but I may be wrong on that.
nope, you're right. And fortunatly, it seems there is a solution.
But more importantly, I think that koha ils systems will do better to globally expose all contents to the web, and free ride on Google at alii indexing, than setting up more search features internally.
I don't understand what you mean here. do you mean having all biblios just indexed by google and rely on google to search ? sorry, but it's unclear to me (maybe it's because it's almost 11PM here, and I have to go to bed ;-) ) -- Paul POULAIN http://www.biblibre.com Expert en Logiciels Libres pour l'info-doc Tel : (33) 4 91 81 35 08
Paul Poulain writes
I don't understand what you mean here. do you mean having all biblios just indexed by google and rely on google to search ?
Not only Google. Building a module that would exposes all biblios to the public web as static pages should be a priority for koha development. Then there is a host of engines can can be applied to web pages. So I can search "moby dick jackson heights" and see if the book is at my local public library.
sorry, but it's unclear to me (maybe it's because it's almost 11PM here, and I have to go to bed ;-) )
It's 2:28 here, so you may excuse my very early morning ramblings... Cheers, Thomas Krichel http://openlib.org/home/krichel http://authorclaim.org/profile/pkr1 skype: thomaskrichel
Op dinsdag 16 november 2010 20:29:05 schreef Thomas Krichel:
Not only Google. Building a module that would exposes all biblios to the public web as static pages should be a priority for koha development. Then there is a host of engines can can be applied to web pages. So I can search "moby dick jackson heights" and see if the book is at my local public library.
You can do that anyway. Static pages aren't necessary for this. -- Robin Sheat Catalyst IT Ltd. ✆ +64 4 803 2204
participants (8)
-
Clay Fouts -
Fridolyn SOMERS -
Galen Charlton -
Marc Chantreux -
Miguel Angel Calvo Lázaro -
Paul Poulain -
Robin Sheat -
Thomas Krichel