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 was posted in counter, sushi. Bookmark the permalink. Both comments and trackbacks are currently closed.
Need help with the Commons? Visit our
help page
Send us a message
Skip to toolbar