brototyp
commented
2 years ago What I thought of previously was that a user doesn't have to bother creating their own queue if they want to persist their events. An argument "true" or "false" would do and we would do the rest of work from that.
That's a legit point. I think there is a bit of tweaking we can do with this implementation to make the usage easier. The think I really like with this implementation that it is very customizable. A user of the SDK would be able to implement yet another queue that fits their very special need, e.g. encrypt and persist it, or persist it in a database or so.
Maybe the persisted: Bool parameter could be in a convenience initializer. This way we could have the best of both worlds. At the same time: Maybe the persisted queue should become the default queue. If it is reliable, I think it might be worth the tradeoff (reduced performance but no (or much less) event loss).
This is for the most of it a copy of PR #377.