[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [DISCUSS] Goals, Requirements and API for journaled events

in the matter of API I would suggest to make the Seek enum members
upercased (since they are static final fields of enum).
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 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

pon., 31 gru 2018 o 09:52 Christian Schneider <chris@xxxxxxxxxxxxxxxxx>

> I have added some goals and requirements for the journaled events.
> These are currently just ideas and are open for discussion. One key
> discussion point is if we limit ourself to just one partition in kafka
> terminology.
> Unlike kafka the API is also just pure pub/sub.
> An initial API can be found at:
> I am not sure if the API really works as it is not yet real life tested.
> When looking at the API be aware that currently the goal is to not support
> sharding (partitions).
> Cheers,
> Christian
> --
> --
> Christian Schneider
> Computer Scientist

Pozdrawiam / Regards,
Dominik Przybysz