Just as a facility for users... I think it would be easier to prototype consumers and producer by simply doing new Consumer("tcp://HOST:PORT") or new Producer("tcp://HOST:PORT")...
on the other project I work (ActiveMQ Artemis) we used to do a similar way to what Kafka does..we then provided the URI support and I now think the URI was a lot easier. I'm just trying to leverage my experience into here... I'm an apache committer at ActiveMQ Artemis.. I think I could bring some goodies into Kafka.. I see no reason to be a competitor.. instead I'm all up to contribute here as well. And I was looking for something small and easy to start with. On Thu, Oct 5, 2017 at 10:15 AM, Jay Kreps <j...@confluent.io> wrote: > Hey Clebert, > > Is there a motivation for adding a second way? We generally try to avoid > having two ways to do something unless it's really needed...I suspect you > have a reason for wanting this, though. > > -Jay > > On Mon, Oct 2, 2017 at 6:15 AM Clebert Suconic <clebert.suco...@gmail.com> > wrote: > >> At ActiveMQ and ActiveMQ Artemis, ConnectionFactories have an >> interesting feature where you can pass parameters through an URI. >> >> I was looking at Producer and Consumer APIs, and these two classes are >> using a method that I considered old for Artemis resembling HornetQ: >> >> Instead of passing a Properties (aka HashMaps), users would be able to >> create a Consumer or Producer by simply doing: >> >> new Consumer("tcp::/host:port?properties=values;properties=values...etc"); >> >> Example: >> >> >> Instead of the following: >> >> Map<String, Object> config = new HashMap<>(); >> config.put(ConsumerConfig.BOOTSTRAP_SERVERS_CONFIG, "localhost:9999"); >> config.put(ConsumerConfig.RECEIVE_BUFFER_CONFIG, -2); >> new KafkaConsumer<>(config, new ByteArrayDeserializer(), new >> ByteArrayDeserializer()); >> >> >> >> Someone could do >> >> new KafkaConsumer<>("tcp://localhost:9999?receive.buffer.bytes=-2", >> new ByteArrayDeserializer(), new ByteArrayDeserializer()); >> >> >> >> I don't know if that little API improvement would be welcomed? I would be >> able to send a Pull Request but I don't want to do it if that wouldn't >> be welcomed in the first place: >> >> >> Just an idea... let me know if that is welcomed or not. >> >> If so I can forward the discussion into how I would implement it. >> -- Clebert Suconic