Refactor utils package

[radu-matei]

As @silvin-lubecki pointed out in #8, utils is not an ideal package name - moreover, the package also mixes an interface declaration for a CRUD store, with its filesystem implementation.

While this approach mostly made sense for Duffle, now that the package has moved out of Duffle and is intended to be imported by other projects, we should refactor the entire package. Here's what I had in mind:

• move the filesystem implementation of the crud.Store package back into Duffle.
• move the current crud.Store interface into a top-level crud package in this package - not 100% sure this is a good idea though, but at the same time, I also really like this interface being exported, such as consumers can directly use claimstore.Store and pass an implementation for this interface.

What do you think?

[silvin-lubecki]

I'm fine with what you proposed. Just about the interface, a more Go would be just to not expose the interface and let the package consumer create their own interface, maybe simpler, and which will fit exactly their needs. But to be honest I'm really fine with both ways 👍

[radu-matei]

On the other hand, as @technosophos pointed out, the reason for having this repo in the first place is so that people don't have to take a dependency on Duffle - and us moving this back into Duffle means that anywhere people using this package want to store claims on a local filesystem, they will either import Duffle (if we move it back there), or reimplement themselves.

[silvin-lubecki]

Well, then I see 2 solutions:
1/ Remove all the store from this package, if you want to persist claims then vendor duffle
2/ Move all the claim store (and maybe other stores) here, not just the crud store.
WDYT?

[technosophos]

On utils, yes -- that name should be removed. I think the go docs even say not to use it as a package name. I should have just deleted that when moving.

IMO, the crud store is sort of an unnecessary abstraction. It would make more sense to just refactor this into a claims storage thing, and only put the claims store in here. (CRUD feels sort of unhelpfully generic). I wasn't viewing this PR as a refactor. But if that is what we'd all like, I can do that.

As for the implementation of storage, I am not sure what the reasoning would be for not providing an implementation. If the purpose of the library is to make it easy to implement the spec, then shipping a library that had interfaces but no implementations just means that we have to educate out users not just on how to consume the library, but also how to implement its underpinnings. I mean, I guess I understand not wanting to have a dozen different drivers checked in here... but... they have to get checked in somewhere, and this seems to me to be a better place than in Duffle.

[silvin-lubecki]

I agree with removing the crud store abstraction and put all the store implementations here 👍

[technosophos]

Okay. I will give that a shot on Friday this week, and then get the outstanding PR on Duffle updated to use it.