Hi, I looked at the API considering how we could use it for our replication use case. I identified one key concept that seemed to be missing, the indexing of messages with monotonically increasing offsets.
For replication, we leverage those offsets extensively, for instance to efficiently compute sub ranges of messages, to skip range of messages, to delay processing of messages, to clean up resources, etc. If we want to leverage the journaled event API to guarantee portability, it seems to me that we'd need to have the offset or an equivalent construct part of the API. How about adding a "getOffset" signature and documenting the offset requirement in the Position interface ? Another unclear intention to me in the API, is the support for partitions (similar to Kafka). The documentation indicates it is not a goal, however the API seems to contain some hints for multi-partition support such as the "TopicPosition" interface. How about supporting multiple partitions in the API by allowing to specify a key (with a semantic similar to Kafka) in the "newMessage" signature ? +1 with moving the "positionToString" in the Position interface. It'll avoid casting the Position instances in the implementations. +1 with Dominik suggestion to pass a DTO to subscribe method. Regards, Timothee Le lun. 31 déc. 2018 à 11:28, Christian Schneider <[email protected]> a écrit : > Am Mo., 31. Dez. 2018 um 10:24 Uhr schrieb Dominik Przybysz < > [email protected]>: > > > > > Maybe also consider using DTOs as input parameter in Messaging interface > > methods, because it would make it easier for future extensions without > > method overloading e.g. instead of > > > > Subscription subscribe(String topic, Position position, Seek seek, > > Consumer<Message> callback); > > > > you can use > > > > Subscription subscribe(SubscriptionSpecification > > subscriptionSpecification); > > > > class SubscriptionSpecification { > > String topic; > > Position position; > > Seek seek; > > Consumer<Message> callback; > > } > > > > It would also allow for setting default values for parameters. > > > > I have no strong opinion about this. What do others think? > > > > > I would like to ask why tle Messaging interface has methods like > > positionFromString and positionToString? It looks like those methods > should > > belong to the interface Position, isn't it? The same with the method > > newMessage. I don't see an obvious connection between method send and > > subscribe. Maybe consider splitting the Messaging interface into smaller > > ones? > > > > Position as well as Message currently are interfaces. So we need some way > to create the provider specific objects. So I think positionFromString as > well as newMessage can only be on the interface the provider supplies as a > service. The method positionToString() can be on the Position interface of > course. I am fine with moving it. > > Send and subscribe could live on different interfaces but the provider must > then offer services for both interfaces. A common interface is more > convenient when you want to inject the service into an object that wants to > send and receive but on the other hand having separate interfaces makes > each single interface more concise and easier to evolve. Like above I do > not have a strong opinion about this. > > Cheers > Christian > > -- > -- > Christian Schneider > http://www.liquid-reality.de > > Computer Scientist > http://www.adobe.com >
