[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
address@hidden |Full Demos at http://liblime.com/koha |1(888)KohaILS