[Koha-devel] Some dev_week Scratchings

[Joshua Ferraro]

Hi all,

I've just cleaned up the naming conventions and some of the code
and documentation issues in Biblio.pm in dev_week. My goal was to
make some sense of the sheer volume of code, weed out the unused
and useless functions, and re-name the used functions according
to our coding guidelines. I didn't intend to do this originally
for dev_week but unfortunately I just couldn't work with client
requirements with the code in such an unreadable state.

Toins, feel free to update rel_3_0 with my changes.

Just a quick update on the current state of dev_week:

1. The searching options have been greatly expanded. If you haven't
looked lately, you'll want to check out the latest record.abs,
bib1.att, ccl.properties files:

  a. The dev_week API uses CCL as the default query language for 
	interaction between the scripts and Zebra, though it does 
	support CCL and PQF if passed ccl= or pqf= as the first 
	part of a query.

  b. Getting your records up to snuff might be the most difficult
	part of a migration process. At some point soon we're
	going to need to put together a cataloging guide for
	catalogers using Koha to help maximize Koha's capabilities.
	in the meantime, expect to spend some time feeding your
	records through some pre-processing scripts.

  c. There are internationalization issues with dev_week that I
	haven't had a chance to explore ... also no support for
	UNIMARC yet, but I think paul and hdl are working on this.
	I expect once a few of my clients' systems go live I'll 
	have some room to breath and take a look at these issues.

2. Items data is no longer updated on-the-fly for circulation -- it's
	just too much of a performance hit. There's a batch script for
	keeping the index up to date that you can run every 5 minutes or
	so to keep things up to date.

3. I removed all the proc-hungry functions in circulation and turned on
	warnings. Speed is up at least 80% from rel_2_2, and that's
	without mod_perl turned on.

4. I'm considering eliminating the old search API from the Intranet 
	rather than maintain a wrapper for it. If anyone has any
	objections, speak up quickly :-).

5. I'm planning to remove additionalauthors and bibliosubject from 
	dev_week because we've created some better ways to handle 
	repeatable data by pulling it directly from the MARC (and
	FYI: additionalauthors and bibliosubject don't work as 
	advertised in rel_2_2, but that's another story :-))

6. This evening I'll be taking a look at the rel_3_0 code for reserving
	specific items and if it's stable, merging it into dev_week.
	
7. NPL will be doing user-testing of the Intranet tomorrow in anticipation
	of their go-live date in early October. I'll post the results of
	this test as soon as it's completed.

8. Authorities management is currently broken in dev_week, but I plan to
	fix it asap.

9. I've done something potentially confusing related to itemtypes in partial
	fullfillment of a NPL's need for a smaller set of circ rules without
	losing all their others. What I've done is to create an authorized
	value called CCODE that is hard-coded in the code to appear as a 
	search point. CCODE is the old itemtype for NPL and NPL uses a new
	set of itemtypes for actual circulation rules.

	However, I may need to adjust how circulation rules are applied to allow
	item-level circulation rules (so that for instance, a record can
	have multiple items, each with different circ rules) which is required
	by almost every US Public library. I will post more about this issue
	as soon as I have a plan -- ideas are welcome :-).

10. Owen and I are going to begin using bugzilla to track issues with dev_week
	now that things are stabilized and will be using the rel_2_4 branch.

11. Migrating from a previous version of Koha to dev_week is nothing
	short of a nightmare :-). In addition to the need to fix broken
	records and normalize existing records, there's the added burden
	of dealing with improperly encoded records. These issues need to be
	dealt with on a case-by-case basis because of the diversity of 
	platforms out there. There's also an incredible learning curve
	for Zebra, both in terms of installation (ie, getting your data
	into zebra and having it run), and customization (ie, getting it
	to search what and how you want). Just a heads up for any of you
	looking to try this out.

Well, that's all for now ... have a good rest of the weekend :-).

Cheers,

-- 
Joshua Ferraro                       SUPPORT FOR OPEN-SOURCE SOFTWARE
President, Technology       migration, training, maintenance, support
LibLime                                Featuring Koha Open-Source ILS
jmf at liblime.com |Full Demos at http://liblime.com/koha |1(888)KohaILS