Re: [Proposal] Create new sub project for journaled messaging
I'm not sure I got the scope.
Is it a new pub/sub system like Kafka or Google PubSub (or even
Is it something like eventadmin on cloud (like we do in Cellar with
If it's just a pure pub/sub, I don't see a huge value compared to Kafka.
About a spec, if we only have one impl of the spec, and the spec is
mainly "focused" on the current impl, not sure it makes sense as well.
On 22/12/2018 09:38, Christian Schneider wrote:
> Some Background
> At Adobe I and two colleagues Timothee Maret and Alexei Krainiouk work on
> making the AEM content publishing fit for the cloud. It is about
> transporting content from author instances that are only visible to a
> customer to outside facing instances that handle the load. For this effort
> it is important to have a reliable pub/sub messaging with support of a
> history where each consumer can decide where to start consuming from.
> We found that Apache Kafka is a good fit function wise but a little heavy
> regarding deployment and management. So to be more versatile we thought
> about encapsulating the messaging using an API and providing
> implementations for different backends.
> Unfortunately there is no existing API that solves this.
> Use case and API sketch
> So we created a description of the use cases as well as a sketch for a
> minimal API.
> See https://github.com/cschneider/journaled-events/blob/master/README.md
> We would like to develop this API as well as implementations as a sub
> project at Apache Aries.
> The main reason for choosing Aries is that David told us that there is
> interest in a OSGi spec about a similar purpose. So we might also bring
> this into an OSGi spec.
> Alexei and Timothee are not yet committers at Aries. I think we can work
> with them using the normal contribution model for the start and make them
> committers after a few PRs.
> So what do you think?
> As a first step I would like to discuss if the Aries PMC is interested in
> giving this effort a home. After that we can discuss the actual API as
> well as possible usages and backends.
Talend - http://www.talend.com