Hi Stefan, On 30 March 2017 at 15:55, Stefan Egli <[email protected]> wrote:
> Hi Ian, > > On 30/03/17 16:37, "Ian Boston" <[email protected] on behalf of > [email protected]> wrote: > >Why Kafka ? > >That doesnt make sense given all the prior discussions about not binding > >to > >proprietary third party stacks, unless this is being implemented because > >you have been told to support a specific use case by a manager. > > It's requirements driven, yes. > For the sake of the community they should be shared if they are to be implemented under the Sling project. If the requirements can't be shared, then perhaps it's better off implementing somewhere else. We don't want to get accused of not being a good Apache project ? > > That doesn't mean it can't be implemented in an extensible way. As > mentioned in the Jira I could see that this could use the MoM API and hook > Kafka in that way - have to yet test how that would work. > > The main different between this approach and mom/jobs/core is that this > aims to be compatible with event/api. > That is what mom/jobs/core was trying to do. Sling Events API is semantically incompatible with distributed messaging, which is why it failed to be 100% compatible. ymmv If you must have 100% compatibility, then don't use MoM API. I dont know how you will really do "distributed' and "messaging" given parts of the Sling Events API need to query a centralised store. IIUC the recommended way of doing this in Kafka is to stream the events into something that can be queried and query that (eg MongoDB, Cassandra etc). The MoM API supports that mechanism already with a listener on the management topics. Apparently you can query Kafka directly, but its messy and requires your data model becomes specific to Kafka. Not recommended. Best Regards Ian > > Cheers, > Stefan > > >
