Github user bbende commented on the issue:
https://github.com/apache/nifi/pull/2702
@MikeThomsen I've only spent a couple of minutes looking at this, but I'm
not sure it can work out as nicely as you are hoping... the controller service
API here is heavily dependent on the actual pulsar client API.
The only way you can get the transparent swapping between processors and CS
impls is if the client API is hidden behind the CS impl. For example with
HBase, we have...
- HBase processors (no dependency on hbase-client, dependency on hbase CS
api)
- HBase CS API (no dependency on hbase-client)
- HBase CS 1.1.2 impl (dependency on hbase-client 1.1.2)
So because the processors and CS API do not know about hbase-client, then
we can transparently provide new implementations without changing the
processors.
In this case we have...
- Pulsar processors (depends on Pulsar client 1.21.0-incubating)
- Pulsar CS API (depends on Pulsar client 1.21.0-incubating)
- Pulsar CS Impls (depends on Pulsar client 1.21.0-incubating)
I'm not saying the current setup is bad, just mentioning that it won't work
out the way the hbase setup works.
The trade-off is that in order to achieve the hbase setup you essentially
need to recreate parts of their client API and depending how much you have to
recreate, it may not be worth it if you are recreating the entire pulsar client
API just to shield the processors.
Also, something to think about is whether Pulsar's client will work well
across different broker versions. For example, when Pulsar 2.x comes out, will
the 1.x client work well against a 2.x broker? or vice versa?
In Kafka land their client has had issues across versions, like 0.8 client
against 0.9 broker did not perform as well as 0.9 client against 0.9 broker, so
for this reason you really need to use the corresponding client that goes with
the broker.
If Pulsar's client doesn't have this problem, maybe we don't need to worry
at all about this versioning stuff.
---
