When we designed the imag core functionality - the imag “Store” - we
introduced a type called
It turned out that the way we designed this type was a big mistake and turned out to be the first big imag design flaw by now. With this post I try to wrap my head around possible solutions to this flaw.
What is this about?
So we wrote the
It is a wrapper around
std::path::PathBuf, so it is basically a path.
We wanted it to be the path to a store entry, but it should be absolute to the
store root itself.
So a valid StoreId object could be
"note/car" - it would uniquely identify
a file in the store.
We made the StoreId also contain a version part, to be able to write imag
modules which could check their data for compatibility with the current
version of the library.
The Problem is that we just wrapped the path type. A StoreId can be created
PathBuf and even from any
String - which clearly is not the way
it is supposed to be.
We didn’t use the type system enough. We should have designed this type more carefully. Lessons learned, I would say.
I know that I should write I messed up, but as the
StoreId type was
also designed by my friend Marcel, I use the term we.
How to clean this up?
Well, this is the hard part. As we do not have a release yet, we do not have to be backwards compatible, so there is no problem with that.
Anyways, we need to rewrite a lot of code to fix this design flaw. As imag gets more momentum in the rust community, this gets more important. This design flaw is actually blocking some other things, as we cannot rely on the properties of the StoreId as we should be able to.
One idea is to rip out the
StoreId type completely and redefine it. In my
StoreId should only be constructed by the
Store, upon request
by the store user. That means that the user should be able to
store.new_id("module", "path/to/entry") which then creates a new StoreId
that points to
$STORE/module/path/to/entry. That would be a clean way.
StoreId type then may contain functionality to
get and maybe even
delete the entry it points to (so it contains a
reference to the actual
Store object internally).
I’m still not sure about the details. As said, I try to wrap my head around this problem with this very article.