aries-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Timothee Maret <>
Subject Re: [DISCUSS] Goals, Requirements and API for journaled events
Date Wed, 02 Jan 2019 01:05:10 GMT

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

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.



Le lun. 31 déc. 2018 à 11:28, Christian Schneider <>
a écrit :

> Am Mo., 31. Dez. 2018 um 10:24 Uhr schrieb Dominik Przybysz <
> >
> > 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
> Computer Scientist

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message