Sushi

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.
  • Subscribe to this blog

Skip to toolbar