On Tue, 4 Nov 2003, Auvo Finne wrote:
Hello Pat,
I'm sorry maybe to make "stupid" questions, but I have no previous acquaintance with Koha and I don't want yet to dowload and install it.
No problem, although grabbing a copy to download and install is a pretty easy (and painless) process.
Let's make first a dichotomy: database subsystem, other parts of the Koha system. Do you have any description of the database objects? I suppose it's a relational database with tables etc. Which are the tables, fields, field definitions? Are there other database objects the Koha system uses? Views? Procedures? How are they named? Does koha.mysql give the answer?
Yes, we use MySQL to handle the RDBMS. There aren't yet good documents on the database design. We aren't yet using views, stored procedures, or similar DB functionality.
Next there must be an interface (Naming of database objects constitutes part of this interface) between database and the other parts of the system? How is this designed and implemented? ODBC? If Koha is written in Perl and HTML, what is the communication mechanism with database?
You could consider Koha to use three tiers: presentation (HTML generated from perl and HTML::Template) business logic (Perl and DBI) database (MySQL)
Regarding system outside database, it seems as if it had three subsystems, namely intranet/librarian, circulation and OPAC.
the intranet portion is the librarian's interface and includes circulation, acquisitions, and other internal tools. the OPAC handles all of the user/patron facing bits.
What does C4 mean? Circulation module? Is circulation module part of the intranet/librarian subsystem?
C4 is actually a historical name from the early days of development. The initial developers joked that it was all liable to blow up, and nick named the project C4 after the plastic explosive. Fortunately, it has proven quite stable in spite of the name.
Are the user interfaces of these subsystems somehow separated as a subsystem itself? I suppose the UI is mainly written in HTML.
we separate the UI propper by using HTML::Template, which allows us to create HTMLish templates which are then used by the business logic (Perl) code to present data to the end user (library staff or patron)
Are these subsystems replaceable? Can someone for example write a new circulation module (let's say in Java) and replace the old one without disturbing the functioning of other subsystems?
We've tried to be very modular. It is hoped that our next version (2.2) will be even more so. I know that one library wrote a flash based circ front-end for a demo to their library board. It was quite spiffy, and worked very well with the rest of Koha.
We can also describe the deployment of subsystems and components according to machines (clients, servers). Does everything happen on one machine? DBMS on one machine, Apache and Perl on another? Are there any client components? Is Koha browser independent?
Koha proper runs on a single server (there's no reason you couldn't split this out though -- again one of the 2.2 goals is to make this easier). The only client component is a web browser. We've tried to stay browser independant, but there is currently a bit of javascript on some pages which limits us a little bit -- I don't think most libraries would be running the borwsers that don't play well with javascript.
Is Perl the only programming language used? Java? JavaScript? What else?
Perl and (a little bit of) javascript are the only languages current;y used. There is no reason that some functionality couldn't be implemented in another language if a library wanted to do so, but it's not certain that any such new development would make it back into the core. I hope this answers your questions. If anyone else on the devel list would like to expand on what I've written, please do. -pate
Greetings,
Auvo
----- Original Message ----- From: "Pat Eyler" <pate@eylerfamily.org> To: "Auvo Finne" <auvo.finne@cccc.fi> Cc: <koha-devel@lists.sourceforge.net> Sent: Friday, October 31, 2003 6:14 PM Subject: Re: Koha documents?
On Fri, 31 Oct 2003, Auvo Finne wrote:
Dear Pat,
Hello Auvo,
I act as a consult and codeveloper for the Tumaini University (Tanzania)
library system.
One of our alternatives is Koha. To seriously assess the suitability of Koha for Tumaini I would like to see some architectural documents.
Sadly, architectural documents are one of the things that we don't have in abundance. If you were willing to spend a bit of time asking questions (even just passing a list of questions you need answers to), we could probably use them to build a set of answers/documents that might help.
I'm answering this on the koha-devl mailing list as well, hopefully this will help generate a bit more help for you as well.
thanks, -pate
We are applying the universal software development process. This process is very much architecture centric and uses several general or detailed diagrams.
Does it exists any descriptions of Koha main components and their purposes, roles, interaction? Descriptionsof the use of programming languages in implementing these components? Etc.
I'll be grateful if you could help me in getting some of these documents.
Very best wishes,
Auvo Finne Pitkakatu 44, Jyvaskyla, Finland +358 400 646 815 auvo.finne@cccc.fi
Pat Eyler wrote:
Let's make first a dichotomy: database subsystem, other parts of the Koha system. Do you have any description of the database objects? I suppose it's a relational database with tables etc. Which are the tables, fields, field definitions? Are there other database objects the Koha system uses? Views? Procedures? How are they named? Does koha.mysql give the answer?
Yes, we use MySQL to handle the RDBMS. There aren't yet good documents on the database design. We aren't yet using views, stored procedures, or similar DB functionality.
we aren't using views/stored proc because mySQL doesn't handle them :-) I think that's the best reason :-)
Next there must be an interface (Naming of database objects constitutes part of this interface) between database and the other parts of the system? How is this designed and implemented? ODBC? If Koha is written in Perl and HTML, what is the communication mechanism with database?
You could consider Koha to use three tiers:
presentation (HTML generated from perl and HTML::Template) business logic (Perl and DBI) database (MySQL)
you can divide the business logic in 2 subparts : - .pl scripts that builds pages & call .pm for DB stuff - .pm in C4 directory that are used for all DB access (except for admin scripts : i did those script when i begun my involvement in Koha, and had missed the .pm theory)
We can also describe the deployment of subsystems and components according to machines (clients, servers). Does everything happen on one machine? DBMS on one machine, Apache and Perl on another? Are there any client components? Is Koha browser independent?
Koha proper runs on a single server (there's no reason you couldn't split this out though -- again one of the 2.2 goals is to make this easier). The only client component is a web browser. We've tried to stay browser independant, but there is currently a bit of javascript on some pages which limits us a little bit -- I don't think most libraries would be running the borwsers that don't play well with javascript.
* Apache & Perl on differents servers, i don't know if it's possible. If you need high scalability, you can always have X front end servers (apache/perl), accessing 1 mySQL server (for data consistency), and use dns round-robin on front-ends. * Javascript is used in MARC editor, and not "a little". This is a "must have". -- Paul POULAIN Consultant indépendant en logiciels libres responsable francophone de koha (SIGB libre http://www.koha-fr.org)
On 2003-11-05 09:10:07 +0000 paul POULAIN <paul.poulain@free.fr> wrote:
* Apache & Perl on differents servers, i don't know if it's possible.
It is possible. Do we do enough transactions/locking for "X front end servers accessing 1 mySQL server" to be safe? Is anyone doing that yet?
* Javascript is used in MARC editor, and not "a little". This is a "must have".
I think this is a bug, but I won't fix before 2.0 -- MJR/slef My Opinion Only and possibly not of any group I know. Please http://remember.to/edit_messages on lists to be sure I read http://mjr.towers.org.uk/ gopher://g.towers.org.uk/ slef@jabber.at Creative copyleft computing services via http://www.ttllp.co.uk/
participants (3)
-
MJ Ray -
Pat Eyler -
paul POULAIN