Deeper hierarchies are not implausible. For example, a Koha database used by a consortium of academic libraries could have six levels:
Consortium (Koha DB) : University : Campus : Library : Branch : Circulation/Reserve Desk
Thank you for this explanation. I appreciate to learn more about consortium problematics. Being on the question of system parameters, and improvement, can I ask about current Koha syspref management? Parameters are retrieved by Perl scripts from systempreferences table. This table is read and re-read and re-re-read multiple times for sysprefs. Wouldn't it better to have application-wide constants which would be retrieved by perl script? You could create an hierarchical data structure, stored in server RAM, directly accessed by program, which could be map into a XML config file. Easier to browse that DB tables, isnt'it. Here is the picture: <site> <name>Alaska Consortium</name> ... <syspref id="AmazonTag">kdsflkdsl</syspref> <syspref id="... ... <libraries> <libray> <name>Frozen University</name> <syspref id="AmazonKey">...</syspref> ... <libraries> <library> <name>South Campus</name> <syspref id="... </library> <library> <name>East Campus</name> </library> </libraries> </lbrary> <library> <name>Ice Cube University</name> <syspref id="AmazonKey">...</syspref> ... </library> </lbraries> </site> My 2c! _______________________________________________ Koha-devel mailing list Koha-devel@lists.koha.org http://lists.koha.org/mailman/listinfo/koha-devel