Hi
I have just spotted this.
I would be a little -1 encrypting headers these are NOT safe to encrypt. The
whole original reason for headers was for non-sensitive but transport or other
meta information details, very akin to tcp headers, e.g. those also are not
encrypted. These should remai
d, is additional bits such as this would levy on top of
headers, e.g. the aes or other data that needs to transport with the record
should be set into headers.
"
On 7 May 2020 at 8:47, Michael André Pearce
wrote:
Hi
I have just spotted this.
I would be a little -1 encrypting headers
*concert = convert
Sent from my iPhone
> On 13 Dec 2017, at 05:35, Michael André Pearce
> wrote:
>
> Hi Randall
>
> What’s the main difference between this and my earlier alternative option PR
> https://github.com/apache/kafka/pull/2942/files
>
> If none then +1.
ecord key/value fields into header values.
>
> @Michael, would you mind if I edited KIP-145 to reflect this proposal? I
> would be happy to keep the existing proposal at the end of the document (or
> remove it if you prefer, since it's already in the page history), and we
> can re
tem 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:
:
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
> wrote:
>
> Hi Clebert
>
> Great kip!
>
> Instead of ‘;’ to separate the host sections
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
nt fields? And if it's
>not specified anywhere in the KIP, why should using the well-known type for
>the header key (e.g. use StringSerializer, IntSerializer, etc) be better or
>worse than using a general serialization format (e.g. Avro, JSON)? And if
>the latter is the choice,
Hi Andrew,
There is already a kip discussion exactly around this if you look for KIP 141
discuss thread.
Cheers
Mike
Sent from my iPhone
> On 18 May 2017, at 18:29, Andrew Coates wrote:
>
> Hi all,
>
> The `ProducerRecord` type has many optional fields and the list has grown
> over differe
+1 , really good to see better operational visibility being added to the broker.
Sent from my iPhone
> On 5 May 2017, at 03:34, Ismael Juma wrote:
>
> Hi everyone,
>
> It seems like the discussion has converged, so I would like to initiate the
> voting process for KIP-143: Controller Health Me
My vote would be with 2, then 3 then 1.
Could I suggest maybe an option 4.
that is option 2 but with a note that there is an intent in 1/2 years time to
deprecate the old way (under another kip). This way books materials can be
updated over a period, code won't be making compile warnings today.
Hi Ewan,
So on the point of JMS the predefined/standardised JMS and JMSX headers have
predefined types. So these can be serialised/deserialised accordingly.
Custom jms headers agreed could be a bit more difficult but on the 80/20 rule I
would agree mostly they're string values and as anyhow you
If it's a choice of either or. I would vote keep as is. At least then people
can write their own api wrappers easily with not many lines of code, like the
one supplied.
Sent from my iPhone
> On 1 May 2017, at 18:34, Matthias J. Sax wrote:
>
> Hi,
>
> I am personally not a big fan of providin
Agreed, I think it is better to either support transactions properly and fully
to the level or expectation normally associated with a transactional system. Or
don't provide it at all.
Having a half way house can be more dangerous.
As I said earlier the issue of message duplication can be hand
14 matches
Mail list logo
