Fair enough on URL encoding but as mentioned it is important to be able to escape, I agree with backslash option.
I would still like some form of prefix to the string to denote it is for kafka. E.g. kafka:: (if semicolon separators) Sent from my iPad > On 24 Oct 2017, at 17:27, 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
