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

Reply via email to