Closed emersion closed 9 years ago
Hoodiecrow is not meant to be an actual IMAP server but an integration tests component. Dropping all state and values after restart is a feature and not a bug in this case – whenever you start a test case you should be sure that there are no unexpected values already stored in the server. Using an actual storage backend would be probably quite hard to implement anyway, so I'm interested to see what you come up with in your fork – Hoodiecrow can cut a lot of corners by using the in-memory JSON structure when doing SEARCH, notifying other clients about changes etc.
Okay, I understand that. I was just wondering how to implement async access to the storage while being able to merge new commits made in this repo.
Hello,
I plan to fork hoodiecrow and to implement an abstract storage interface. I would like to be able to use a custom storage instead of a static JSON object. I'll build a storage interface for memory (as it is implemented for now) and for waterline. I would like to know if this could be merged back in hoodiecrow (at least the memory storage interface) or if this is definitely not the goal of this project to provide a flexible storage interface. What do you think?
Thanks :-)