On Tue, Oct 24, 2017, at 22:51, Michael André Pearce wrote: > 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.
I don't think a prefix is necessary here. URLs have a prefix because there are multiple services which you could access (HTTP vs HTTPS, etc.) If you are passing a string to Kafka, the string is for Kafka, not for something else, so the issue doesn't exist. best, Colin > > 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
