Design discussion: moving towards a SerializerWithStringManifest-based Serializer?

[raboof]

With akka 2.4's SerializerWithStringManifest, things can get much simpler: we don't need a PersistedCodec anymore.

I think it would make sense to rename the current StaminaAkkaSerializer to something like CodecBasedStaminaAkkaSerializer (for compatibility with 'old' persisted events and use cases where you do want a codec) and create a new StaminaAkkaSerializer based on SerializerWithStringManifest.

Now that keeping the metadata separate from the actual serialized data becomes common, it's unclear whether the Persisted case class still makes so much sense: we could skip creating an intermediate Persisted instance, and make separate methods on Persister to produce the manifest and the serialized data independently.

Persisters could be refactored to hold a Map[String, Persister] to look up persisters by manifest, which could make it much simpler and more efficient.

[agemooij]

I briefly looked at your experiments with removing Persisted. Somehow it feels wrong to get rid of the symmetric relation between persist (i.e. T => Persisted) and unpersist (i.e. Persisted => T). The way you are going you don't have access to the "manifest" anymore after persisting. This might not be a problem but I liked the separation of concerns between the persister and the codec from the perspective of understanding the system and reasoning about it. My first instinct is that combining them makes it harder to reason about. I could be wrong of course. I'll have to think about it a bit more.

[raboof]

The idea is that persist would indeed become T => Array[Byte] instead of Persisted, I kept the current one around so I didn't have to rewrite all tests already :)