One of the appalling discoveries when taking a closer look at the MarcEdit 6 codebase, was the presence of 3(!) Z39.50 clients (all using slightly different codebases. This happened because of the ILS integration, the direct Z39.50 Database editing, and the actual Z39.50 client. In the Mac version, these clients are all the same thing — so I wanted to emulate that approach in the Windows/Linux version. And as a plus, maybe I would stop (or reduce) my utter distain at having support Z39.50 generally, within any library program that I work with.
* Sidebar — I really, really, really can’t stand working with Z39.50. SRU is a fine replacement for the protocol, and yet, over the 10-15 years that its been available, SRU remains a fringe protocol. That tells me two things:
- Library vendors generally have rejected this as a protocol and there are some good reason for this…most vendors that support (and I’m thinking specifically about ExLibris), use a custom profile. This is a pain in the ass because the custom profile requires code to handle foreign namespaces. This wouldn’t be a problem if this only happened occasionally, but it happens all the time. Every SRU implementation works best if you use their custom profiles. I think what made Z39.50 work, is the well-defined set of Bib-1 attributes. The flexibility in SRU is a good thing, but I also think it’s why very few people support it, and fewer understand how it actually works.
- That SRU is a poor solution to begin with. Hey, just like OAI-PMH, we created library standards to work on the web. If we had it to do over again, we’d do it differently. We should probably do it differently at this point…because supporting SRU in software is basically just checking a box. People have heard about it, they ask for it, but pretty much no one uses it.
By consolidating the Z39.50 client code, I’m able to clean out a lot of old code, and better yet, actually focus on a few improvements (which has been hard because I make improvements in the main client, but forget to port them everywhere else). The main improvements that I’ll be applying has to do with searching multiple databases. Single search has always allowed users to select up to 5 databases to query. I may remove that limit. It’s kind of an arbitrary one. However, I’ll also be adding this functionality to the batch search. When doing multiple database searches in batch, users will have an option to take all records, the first record found, or potentially (I haven’t worked this one out), records based on order of database preference.
Wireframes:
Main Window:
Z39.50 Database Settings:
SRU Settings:
There will be a preferences panel as well (haven’t created it yet), but this is where you will set proxy information and notes related to batch preferences. You will no longer need to set title field or limits, as the limits are moving to the search screen (this has always needed to be variable) and the title field data is being pulled from preferences already set in the program preferences.
One of the benefits of making the changes is that this folds the z39.50/sru client into the Main MarcEdit application (rather than as a program that was shelled to), which allows me to leverage the same accessibility platform that has been developed for the rest of the application. It also highlights one of the other changes happening in MarcEdit 7. MarcEdit 6- is a collection of about 7 or 8 individual executables. This makes sense in some cases, less sense in others. I’m evaluating all the stand-alone programs and if I replicate the functionality in the main program, then it means that while initially, having these as separate program might have been a good thing, the current structure of the application has changed, and so the code (both external and internal) code needs to be re-evaluated and put in one spot. In the application, this has meant that in some cases, like the Z39.50 client, the code will move into MarcEdit proper (rather being a separate program called mebatch.exe) and for SQL interactions, it will mean that I’ll create a single shared library (rather than replicating code between three different component parts….the sql explorer, the ILS integration, and the local database query tooling).
Questions, let me know.
–tr