+1... I will update the KIP by the weekend... (I am taking this on my spare time.. although I can rush it if anyone needs it sooner).
On Tue, Oct 24, 2017 at 12:27 PM, Colin McCabe <cmcc...@apache.org> wrote: > Hi Clebert, > > As some other people mentioned, a comma is probably not a great choice > for the entry separator. We have a lot of configuration values that > already include commas. How about using a semicolon instead? > > You also need an escaping system in case someone needs a semicolon (or > whatever) that is part of a configuration key or configuration value. > How about a simple backslash? And then if you want a literal backslash, > you put in two backslashes. > > On Thu, Oct 19, 2017, at 18:10, Michael André Pearce wrote: >> Just another point to why I’d propose the below change to the string >> format I propose , is an ability to encode the strings easily. >> >> We should note that it’s quite typical for serializers to user a >> schematic registry where one of their properties they will need to set >> would be in some form like: >> >> schema.registry.url=http://schema1:80,schema2:80/api >> >> So being able to safely encode this is important. >> >> Sent from my iPhone >> >> > On 20 Oct 2017, at 01:47, Michael André Pearce >> > <michael.andre.pea...@me.com> wrote: >> > >> > Hi Clebert >> > >> > Great kip! >> > >> > Instead of ‘;’ to separate the host sections with the params section could >> > it be a ‘?’ >> > >> > And like wise ‘,’ param separator could this be ‘&’ (keep the ‘,’ for host >> > separator just makes easier to distinguish) >> > >> > Also this was it makes it easier to encode params etc as can just re use >> > url encoders. > > Please, no. URL encoders will mangle a lot of things horribly (like > less than signs, greater than signs, etc.) We should not make this a > URL or pseudo-URL (see the discussion above). We should make it clear > that this is not a URL. > >> Invalid conversions would throw InvalidArgumentException (with a description >> of the invalid conversion) >> Invalid parameters would throw InvalidArgumentException (with the name of >> the invalid parameter). > > This will cause a lot of compatibility problems, right? If I switch > back and forth between two Kafka versions, they will support slightly > different sets of configuration parameters. It seems saner to simply > ignore configuration parameters that we don't understand, like we do > now. > > best, > Colin > > >> > >> > Also as like many systems it typical to note what the connection string is >> > for with a prefix eg ‘kafka://‘ >> > >> > Just makes it obvious when an app has a list of connection strings in >> > their runtime properties which is for which technology. >> > >> > Eg example connection string would be: >> > >> > kafka://host1:port1,host2:port2?param1=value1&parm2=value2 >> > >> > Cheers >> > Mike >> > >> > Sent from my iPhone >> > >> >> On 19 Oct 2017, at 19:29, Clebert Suconic <clebert.suco...@gmail.com> >> >> wrote: >> >> >> >> Do I have to do anything here? >> >> >> >> I wonder how long I need to wait before proposing the vote. >> >> >> >> On Tue, Oct 17, 2017 at 1:17 PM, Clebert Suconic >> >> <clebert.suco...@gmail.com> wrote: >> >>> I had these updates in already... you just changed the names at the >> >>> string.. but it was pretty much the same thing I think... I had taken >> >>> you suggestions though. >> >>> >> >>> >> >>> The Exceptions.. these would be implementation details... all I wanted >> >>> to make sure is that users would get the name of the invalid parameter >> >>> as part of a string on a message. >> >>> >> >>> On Tue, Oct 17, 2017 at 3:15 AM, Satish Duggana >> >>> <satish.dugg...@gmail.com> wrote: >> >>>> You may need to update KIP with the details discussed in this thread in >> >>>> proposed changes section. >> >>>> >> >>>>>> My proposed format for the connection string would be: >> >>>>>> IP1:host1,IP2:host2,...IPN:hostn;parameterName=value1;parameterName2=value2;... >> >>>> parameterNameN=valueN >> >>>> Format should be >> >>>> host1:port1,host2:port2,…host:portn;param-name1=param-val1,.. >> >>>> >> >>>>>> Invalid conversions would throw InvalidArgumentException (with a >> >>>> description of the invalid conversion) >> >>>>>> Invalid parameters would throw InvalidArgumentException (with the >> >>>>>> name of >> >>>> the invalid parameter). >> >>>> >> >>>> Should throw IllegalArgumentException with respective message. >> >>>> >> >>>> Thanks, >> >>>> Satish. >> >>>> >> >>>> On Tue, Oct 17, 2017 at 4:46 AM, Clebert Suconic >> >>>> <clebert.suco...@gmail.com> >> >>>> wrote: >> >>>> >> >>>>> That works. >> >>>>> >> >>>>>> On Mon, Oct 16, 2017 at 6:59 PM Ted Yu <yuzhih...@gmail.com> wrote: >> >>>>>> >> >>>>>> Can't you use IllegalArgumentException ? >> >>>>>> >> >>>>>> Some example in current code base: >> >>>>>> >> >>>>>> clients/src/main/java/org/apache/kafka/clients/Metadata.java: >> >>>>>> throw new IllegalArgumentException("Max time to wait for metadata >> >>>>> updates >> >>>>>> should not be < 0 milliseconds"); >> >>>>>> >> >>>>>> On Mon, Oct 16, 2017 at 3:06 PM, Clebert Suconic < >> >>>>>> clebert.suco...@gmail.com> >> >>>>>> wrote: >> >>>>>> >> >>>>>>> I updated the wiki with the list on the proposed arguments. >> >>>>>>> >> >>>>>>> I also changed it to include a new Exception class that would be >> >>>>>>> named >> >>>>>>> InvalidParameterException (since I couldn't find an existing >> >>>>>>> Exception >> >>>>>>> class that I could reuse into this). (I could review the name or the >> >>>>>>> exception of course.. just my current proposal) >> >>>>>>> >> >>>>>>>> On Mon, Oct 16, 2017 at 5:55 PM, Jakub Scholz <ja...@scholz.cz> >> >>>>>>>> wrote: >> >>>>>>>> Hi Clebert, >> >>>>>>>> >> >>>>>>>> I think it would be good if this could cover not only KafkaConsumer >> >>>>> and >> >>>>>>>> KafkaProducer but also the AdminClient. So that all three can be >> >>>>>>> configured >> >>>>>>>> the same way. >> >>>>>>>> >> >>>>>>>> The bootstrap servers are a list - you can provide multiple >> >>>>>>>> bootstrap >> >>>>>>>> servers. Maybe you add an example of how that will be configured. I >> >>>>>>> assume >> >>>>>>>> it will be >> >>>>>>>> "host:port,host2:port2;parameterName=value1;parameterName2=value2" >> >>>>> but >> >>>>>>> it >> >>>>>>>> would be great to have it documented. >> >>>>>>>> >> >>>>>>>> Thanks & Regards >> >>>>>>>> Jakub >> >>>>>>>> >> >>>>>>>> On Mon, Oct 16, 2017 at 11:30 PM, Clebert Suconic < >> >>>>>>> clebert.suco...@gmail.com >> >>>>>>>>> wrote: >> >>>>>>>> >> >>>>>>>>> I would like to start a discussion about KIP-209 >> >>>>>>>>> (https://cwiki.apache.org/confluence/display/KAFKA/KIP- >> >>>>>>>>> 209+-+Connection+String+Support) >> >>>>>>>>> >> >>>>>>>>> This is an extension of my previous thread: >> >>>>>>>>> http://mail-archives.apache.org/mod_mbox/kafka-dev/201710. >> >>>>>>>>> mbox/%3cCAKF+bsoFbN13D-u20tUsP6G+aHX4BUNk=S8M4KyJxAt_ >> >>>>>>>>> oyv...@mail.gmail.com%3e >> >>>>>>>>> >> >>>>>>>>> this could make the bootstrap of a consumer or producer similar to >> >>>>>>>>> what users are already used when connecting into other systems, >> >>>>> being >> >>>>>>>>> a simple addition to Producer and Consumer, without breaking any >> >>>>>>>>> previous client usage. >> >>>>>>>>> >> >>>>>>>>> >> >>>>>>>>> -- >> >>>>>>>>> Clebert Suconic >> >>>>>>>>> >> >>>>>>> >> >>>>>>> >> >>>>>>> >> >>>>>>> -- >> >>>>>>> Clebert Suconic >> >>>>>>> >> >>>>>> >> >>>>> -- >> >>>>> Clebert Suconic >> >>>>> >> >>> >> >>> >> >>> >> >>> -- >> >>> Clebert Suconic >> >> >> >> >> >> >> >> -- >> >> Clebert Suconic -- Clebert Suconic
