A couple of years ago, I started building a Sushi client. Sushi is a protocol for accessing standardized usage reports from our vendors. These reports, called Counter reports, quantitatively describe the usage of our electronic collections. I needed a client because at the time we didn’t have any automated way to gather these reports.
It seemed like a good idea. But there have been problems. Specifically:
- The transition from Counter 4 to Counter 5 has meant that I’ve had to maintain separate code for both versions.
- Vendors don’t have much incentive to make their Sushi implementations usable, so the interfaces are often difficult to work with.
- I usually only need Counter reports about twice a year, so that the unfamiliarity of this project annoyed me each time I came back to it. I was always having to relearn what I had figured out 6 months ago.
There have been some improvements, too. Counter 5 supports JSON, so there’s no need to work with XML, which is really nice. Plus, almost all vendors have Counter 5 service now, so I’m dropping support for Counter 4 from my client.
I’m not sure how long I’ll continue to maintain this project. Alma, our new LSP, has Sushi functionality built in. I haven’t tried Alma’s implementation, but it is quite likely better than my scripts. And I wouldn’t have to maintain it! Sounds pretty good…
This entry is licensed under a Creative Commons Attribution 4.0 International license.
