►
From YouTube: 2022-10-04 meeting
Description
cncf-opentelemetry@cncf.io's Personal Meeting Room
A
B
C
A
Okay,
let's
start
the
custom
messages.
I
saw
your
PR
ending
commented
on
it,
I
don't
know
if
you
had
it
ever
time
to
to
take
a
look
at
it.
I
guess:
I
have
one
primary
concern,
which
is
about
the
use
of
sequence,
IDs
inside
the
custom
messages
and
the
concerns
that
were
were
introducing
a
new
place
with
sequence
like
this
one.
We
already
have
a
place.
The
the
alter
messages
also
have
sequence
IDs.
C
I
think
there's
two
issues
with
using
the
top
level
sequence.
That
is
one
one
is
that
we
only
have
in
the
One
Direction
right
now
we
could
add
them
the
other
direction,
but
the
custom
message
is
going
to
go
both
ways,
so
we
would
need
them
either
direction.
The
other
thing
is,
and
I
meant
to
clarify
this
I
did
see
your
comments.
Last
night,
I
just
been
busy
and
haven't
had
a
chance
to
look
into
it
more,
but
I
believe
those
sequence.
C
Basically,
when
you
send
a
message
and
you
get
a
response
or
you
know
an
act
for
that
message-
you
you
want
to
know
what
that
act
is
for
I.
Don't
think
you,
if
you
use
a
top
level
sequence,
ID
I,
don't
think
you'd
have
access
to
that
now
you
know
they're.
Obviously
we
could
change
some
things.
There,
I
I'm
I'm,
pretty
torn
as
to
how
this
should
be
really
handled.
C
That
I
think
there's
there's
two
things
that
are
important
with
custom
messages,
one
having
some
way
to
know
whether
or
not
the
agent
supports
that
message,
and
so
he
you
know
that
was
part
of
probably
built
into
the
act
of
a
not
supportive
response,
so
that
you
know
that
you're
not
waiting
for
some
other
response,
or
you
know
that
you
know
if
there's
some
side
effect,
that
you're
expecting
that
that's
not
going
to
happen
right
right,
I,
agree
with
that.
I
think
that's.
A
Yeah
I
think
that's
that's
that
that
is
necessary.
You
you're
absolutely
right,
because
there
is
no
other
way
to
to
to
communicate
the
capabilities
within
the
custom
messages
right.
If
you
do,
if
you
have
multiple
types
of
custom
messages,
how
do
you
know
the
agent
supports
the
particular
one,
and
you
have
to
be
able
to
respond
to
a
particular
custom
message
with
with
a
response
of
whether
it
was
accepted
or
rejected.
I
do
agree
with
that.
I
think.
That's!
A
That's
fine,
however
I
I
think
so
we
could
add
the
the
sequence
numbers
in
the
opposite
direction
as
well,
and
also
at
the
the
the
acknowledging
numbers
right
and
not
just
for
customer.
So
the
reason
I
if
this
was
only
ever
necessary
for
custom
messages,
I,
would
agree
right.
Let's
put
it
there.
My
worry
is
that
we
will
discover
in
the
future
some
other
capability
that
we
want
to
add
to
to
all
pump
which
requires
acknowledgment.
Just
like
you,
you
require
it
for
custom
messages.
A
We
don't
need
it
now,
but
I
I
can
see
how
it
may
be
possible
that
without
features
that
require
in
the
future,
so
we
will
end
up
with
with
a
situation
when,
when
you
have
an
acknowledgment
number,
a
sequence
number
essentially
at
the
top
level,
the
the
pair
of
those
in
the
agent
to
server
in
the
opposite
direction
and
another
pair
of
those
in
in
the
custom
messaging
and
its
response,
and
that
would
be
a
pretty
undesirable
outcome
right.
A
Let's
say
this
way,
because
it's
going
to
be
very,
very
confusing,
which
one
are
you
going
to
use
right,
I,
agree:
I
want
to
try
to
avoid
that
right,
so
I
would
even
prefer
a
situation
where
we
have
those
sequence
numbers
in
the
top
level
messages
and
they
are
used
only
for
custom
messages
or
even
completely
reserved
for
now
not
used
at
all
for
any
special
logic.
We
just
populate
them.
We
we
put
Auto
incrementing
numbers
there,
although
they
are
unnecessary
for
the
semantics
of
the
communication
that
open
does
today,
but
it
it
opens.
A
It
creates
a
possibility
right
for
in
the
future,
for
us
to
extend
our
pump
in
a
way
that
is
not
confusing.
I
think
the
way
that
I
was
describing.
So
that's,
that's
my
fear.
I'm
I'm
worried
about
us
doing
this
right
now,
just
for
custom
messages
and
then
discovering
it's
not
the
only
use
case
where
we
need
the
sequence
numbers.
C
A
Yeah,
what
do
you
need
where
the
semantics
of
the
particular
operation
require
the
caller
to
be
aware
of
the
the
sequence
numbers
we
could
expose
them
in
the
in
the
client,
API
right
or
the
server
API
or
or
make
it
part
of
the
the
let's
say
you
require.
You
make
a
request
from
the
client
side,
which
requires
a
response
from
the
server
we
could
make
it
work
with
callbacks,
where
you
don't
even
have
to
deal
with
with
a
with
the
sequence
numbers
yourself.
A
It
would
still
be
transparent
for
the
user
of
the
client,
but
underneath
the
implementation
would
use
the
sequence
numbers
there's
a
number
of
options
here
right
you
you
could
do
you
would
you
could
make
it
even
expose
the
the
sequence
numbers
in
the
API
or
you
could
hide
them
and
just
have
the
the
semantics
of
continuations
or
whatever
the
callbacks
or
right
there's.
There
is
a
few
options
that
you
can
do
in
the
API
design
itself.
The
the
protocol
doesn't
necessarily
dictate
exactly.
What
do
you
do
there?
A
So
I
think
it's
fine
right.
If
we
need
the
custom
messages,
let's
say
the
custom
message
is
to
use
the
the
acknowledgments
and
all
that
stuff
sure
let's
have
the
in
the
API.
Let's
expose
the
the
sequence
numbers.
If
we
want
to
do
that,
the
other
operations
don't
need
it,
so
we
don't
expose
it
right.
So
for
computer
remote
configuration
or
status
reporting,
they
are
unnecessary.
A
Make
we
have
one
exactly
and
we
use
it
for
a
specific
purpose
of
detecting
the
lost
data
and
all
that
stuff,
but
here's
another
use
case
where
we
need
sequence
numbers
but
more
than
what
we
have
right,
and
so
what
I'm
saying
is
that
I
think
we
should
seriously
consider
just
adding
the
proper
full,
maybe
a
double
pair
of
sequence,
numbers
and
their
acknowledgments
in
the
messages,
because
it's
it's,
it's
universally
understood
right
what
it
is
like
it's,
not
something
that
we're
inventing
it's
it's
a
clear
concept.
A
Many
protocols
have
the
sequencing
and
the
implementation.
Wise
I
mean
trivial
to
populate
these
fields.
Just
don't
want
to
increment
the
number
and
put
it
there.
So
I
I
I'm
not
worried
about
over
completely
complicating
the
protocol
or
the
implementations.
The
result
result
of
that
I
I
would
prefer
to
to
be
a
bit
complicated
today
and
to
avoid
huge
complications
in
the
future.
Like
that's
what
we
have
to
do
right
sure
to
me,
it
would
be
very
bad
outcome.
C
C
Okay
sounds
good.
The
other
piece
of
feedback
was
about
the
data
and
body
string
and
bytes.
Both
existing
I
I
just
added
them
both
because
it
was
very
low
overhead
and
it
might
be
preferable
for
an
implementer
to
use
one
or
the
other
I.
Don't
I,
don't
know
exactly
what
the
experience
is
like.
You
know,
for
example,
a
node
when
receiving
a
byte
array-
probably
fine,
but
but
you
know
there
might
be
some
desire
to
use
strings
in
some
cases.
A
C
A
C
C
Strictly
necessary,
it's
just
might
make
the
user
experience
a
little
cleaner
in
certain
languages.
A
But
I
would
argue
that
you
can
do
that
in
the
API
again
right.
You
want
to
do
that
in
the
API.
Do
it
in
the
API
expose
an
API
which
gives
you
a
nice
way
to
encode
whatever
data
structure
you
want
into
a
yamo
form,
centralize
it
and
put
it
into
the
the
the
the
field
which
is
which
is
bytes
right.
What
do
you
gain
by
having
two
Fields
one
for
spring
another
for
bytes
at
on
The,
Wire
level?
C
C
Figured
the
the
it
was
like
I,
said,
very
low
overhead
of
adding
both
yeah
and
leaving
it
up
to
the
user.
A
If
it's
just
to
make
the
usage
nicer
like
easier
in
the
code
in
the
code,
you're
working
with
the
client
API
right,
you're,
not
directly
encoding
the
via
wire
data
in
the
client
API,
you
could
have
helpers
or
whatever
something
that
actually
gives
you
that
nice
use
of
usage
right.
So
but
it's
easier,
yeah.
C
I
just
I
just
know
of
a
long
history
of
string,
encoding
issues
with
Junior
developers
and
you
know,
would
rather
not
revisit
them,
and
and
and
maybe
it's
less
of
an
issue
over
just
uses
utf-8
these
days
and
everything's
encoded
and
decoded
etf8.
So
but
but
it
is
nice
that
part
of
offers
a
stream
and
it
sort
of
takes
some
of
the
the
need
to
reason
about
fighting
coding.
C
But
again,
I
I
I
appreciate
your
point
that
it
can.
It
can
be
in
the
API
it
could.
It
could
be.
You
know,
a
helper
function
that
that
somebody
implements
once
and
yeah.
A
C
Yeah,
this
is
a
wire
protocol.
This
is
not,
you
know,
meant
to
be
addressing
usability
issues.
Yeah.
A
That's
that
that
would
be
my
preference
to
be
minimalistic
here
right.
Is
there
anything
that
you
can't
express
in
the
in
a
byte
form
that
you
can
express
using
the
combination
of
three
Fields?
Obviously,
no
right,
that's
not
the
case.
Is
there?
Is
there
some
sort
of
interoperability
issue
that
we're
solving
by
introducing
three
different
fields?
A
If
the
answer
is
yes,
then
I
think
that's
a
strong
argument,
but
I
don't
see
that
here
in
this
particular
case
right
somehow
it
helps
with
with
the
discovery
of
the
type
of
custom
messages
or
introduction
of
the
new
types
of
custom
messages
that
I
would
understand.
You
need
to
have
that
as
part
of
the
wire
data,
but
the
the
argument
that
it
makes
it
easier
to
write
code
that
uses
all
pump.
C
I'm
fine,
with
just
by
by
the
way,
if
I,
would
invite
anyone
to
disagree,
and
we
can
continue
the.
A
A
Okay,
so
let's
maybe
try
to
see
what
the
sequencing
would
look
like
if
we,
if
we
were
to
introduce
it
at
the
top
level,
I
mean
I.
I
can
see
it
in
my
mind,
but
maybe
there's
there's
some
nuances
which
which
I
don't
see.
Maybe
let's
try
to
spell
it
out.
I'll
push
a.
A
C
A
A
Right,
so
are
we
good
with
the
with
the
custom
messages
anything
else
anyone
wants
to
talk
about
for
that
Okay
cool,
so
the
web
socket
messages.
So
why
the
reason
I
I
created
this
I
was
thinking
about
okay.
So
let's
say
one
day:
we
decide
that
we
really
want
to
solve
the
problem
of
some
destinations,
not
accepting
large
messages.
So
how
would
we
do
that
we
will
do?
We
will
have
to
do
the
fragmentation
ourselves
right.
A
So
we
have
to
fragment
the
messages,
our
op-amp
logical
messages
into
small
kind
of
Pep,
socket
level
messages
and
then
do
the
reassembly
and
the
way
you
would
do
that
is
by
so
you
there
is
only
the
the
individual
fragments
are
no
longer
valid,
protobuf
messages.
So
you
are
you
can't
Marshal
and
unmarshall
them
anymore,
so
there
has
to
be
a
mechanism
that
works
on
a
different
level
before
that
that's
a
different
abstraction
level.
A
Essentially,
you
need
an
indication
whether
a
particular
websocket
message
is
a
complete
protobot
message
or
a
continuation
of
a
previous
one,
so
that
you
can
do
the
reassembly
and
do
the
yarn
margin
right.
The
the
way
you
do.
This
can't
be
recorded
inside
the
product
of
message,
obviously,
but
there
is
no
way
no
place
today
to
record
any
other
information.
A
Everything
that
we
have
is
recorded
inside
the
protocol
right
because
there
is
one-to-one
mapping
between
the
websocket
message
and
the
product
message,
and
so
this
kind
of
forces
us
to
have
to
break
this
mapping
to
say
that
there
is
some
sort
of
additional
information
recorded,
alongside
with
the
with
the
with
the
webs,
with
sorry
with
the
product
message.
So
this
is
the
minimal
approach.
I
I
was
able
to
come
up
with
is
sort
of
a
single
byte
header.
A
It
defaults
to
zero
as
a
value
today
and
in
the
future
you
can
introduce.
You
can
use
any
number
of
bits
in
that
header
to
declare
them
for
use
by
by
a
specific
capability,
and
one
of
the
capabilities
would
be
this
example
right,
the
fragmentation
and
reassembly.
So
you
would
use
a
one
bit
to
indicate
whether
that's
that's
that
particular
websocket
has
a
continuation
or
it
doesn't
right.
So
you'd
wait
until
you
receive
the
last
one,
and
that
was
another
example.
A
I
had
I'm
not
remembering
that
what
was
that
yeah,
the
compression-
let's
say
you
want
to
have
a
different
compression,
algorithm
and
websocket-
has
the
built-in
ability
to
compress
messages,
but
it's
only
deflate
algorithm
and
if
you
want
to
use
something
more
modern,
more
efficient
like
this
standard,
you
can't
right.
There's.
No,
it's
not
available,
I
mean
I'm,
not
aware
of
any
implementations,
so
that
would
have
to
be
also
encoded
in
the
header
or
you
negotiate
it
for
the
entire
duration
of
the
connection.
A
That's
also
a
possibility,
but
for
the
for
the
fragmentation,
you
can't
you
have
to
have
an
indication.
You
have
to
have
a
some
sort
of
at
least
one
beat
per
websocket
message
to
do
that
fragmentation.
So
this
is
what
I
wanted
to
discuss,
because
we
have
to
do
it
before
doing
stable.
B
My
initial
reaction
to
it
is
actually
kind
of
triggered
by.
We
have
to
do
this
before
it's
stable,
which
is
interesting
to
me
because,
immediately
my
mind,
leapt
to
kind
of
while
we're
doing
like
an
upgrade
to
the
websocket
connection.
Okay,
through
there
we've
got
HTTP
headers.
We
also
have
the
ability
to
you
know
essentially
version
through
multiple
endpoints
for
that
process.
So,
like
is
this
actually
something
we
need
to
do
on
on
the
wire
or
are
there
other
means
of
kind
of
addressing
kind
of
like
compatibility,
these
changes
going
forward,
yeah.
A
You
are
so
you
can
negotiate
new
capabilities
during
the
connection
phase
right.
You
can
do
that
using
HTTP
headers.
The
client
can
say:
I
want
to
use
the
standard
compression
for
the
messages
and
the
server
can
say.
Yes
do
that
or
no
don't
do
that.
I,
don't
understand
what
it
means
that
works
well
for
capabilities
that
you
can
negotiate
once
per
connection
and
use
for
the
entire
connection.
A
Unfortunately,
I
am
thinking
about
a
possible
future
feature
which
prevents
that
from
from
from
being
possible
to
use
I'm
thinking
about
the
the
the
proxy,
the
the
the
concentrating
proxy,
where
you
have
an
op-amp
proxy,
which
allows
multiple
opamp
clients
to
connect
to
it
using
each
using
its
own
websocket
connection,
and
then
the
proxy
uses
a
single
outgoing
connection
to
the
Oppam
server.
Today,
that's
totally
possible.
You
can
do
that.
A
You
can
Multiplex
multiple
connections
from
opamp
clients
into
a
single
websocket
connection
and
that's
possible,
because
every
single
message
that
we
send
contains
the
the
agent
identifier.
So
you
can
send
it,
you
can
concentrate
them
and
send
them
all
to
the
server.
And
when
you
receive
responses
from
the
server
you
can
demultiplex
them
using
the
instance
ID
and
send
to
the
right
client
connection.
A
Now,
how
does
this
interact
with
you
with
the
new
capabilities
negotiated
right?
It
interacts
because
now,
if
you
have
multiple
clients,
which
support
different
capabilities
and
they
have
to
negotiate
those
capabilities
through
the
proxy,
that's
no
longer
possible
because
the
proxy
is
actually
using
a
single
connection
with
the
server.
So
there
is
only
one
chance
for
that
connection
to
be
negotiated
and
that
negotiation
is
done
by
the
proxy,
not
by
the
client.
So
there's
no
way
to
if
you're,
using
the
proxy
of
the
type
that
I
described.
A
A
You
can
negotiate
capabilities
per
leg
of
connection,
but
not
end
to
end
right.
So
if
the
server
doesn't
understand
how
to
use
Z
standard
compression
how
to
decompress
those
messages
it,
it
needs
to
somehow
indicate
that
it
can't.
But
but
how
do
you
do
that?
If
there
are
different
clients
who
are
connecting
and
they
are
asking
for
different
capabilities,
one
of
them
says
I
want
to
use
this
extra
header,
because
I
use
this
standard
compression
right,
the
and
then
the
other
says
I
want
to
use
fragmentation.
A
So
you
have
a
mix
of
clients
which
support
different
capabilities
and
they
are
asking
for
different
things
and
and
the
server
can't
respond
can
give
them
one
response
right.
It
has
to
them
different,
different
responses,
but
you
can,
because
there
is
a
single
connection
right
and
the
the
response
happens
only
once
per
connection,
so.
C
A
Yes,
yes,
exactly
if
I
don't
need
to
pick
into
the
payload
and
on
the
proxy
I,
probably
don't
my
simplest
implementation
is
to
just
relay
the
messages
from
I
receive
from
the
clients
to
the
server
and
relay
back
right.
All
I
need
to
do
is
to
to
keep
them
up
connecting
connecting
clients,
a
map
of
their
IDs
to
their
connections
and
I
can
relay
them
back.
I,
don't
need
to
decode
the
message.
Why
would
I
decode
the
message
in
a
proxy
unless
I
need
to
somehow
look
into
the
message
and
modify
it?
A
Maybe
but
a
typical
use
case,
but
the
use
case
I'm
thinking
about
is
I
have
millions
of
connecting
agents
I'm
putting
gateways
in
in
some
strategic
places
that
that
concentrates
and
reduces
the
number
of
the
connections
that
go
to
my
server
dramatically
right.
I
can
very
significantly
reduce
the
number
of
connections,
which
is
the
most
expensive
thing
we
have
here
in
this
protocol,
and
they
are
idling.
A
They
are
not
doing
anything
most
of
the
time
so
by
using
this
concentrating
proxy
I
can
very
very
significantly
reduce
the
load
of
the
of
the
server
and
I
can
do
that,
for
example,
very
easily
in
our
collector
Helm
chart
where
we
have
where
we
have
an
agent
per
node
per
kubernetes
node,
and
then
we
have
a
Gateway
One
Gateway.
A
That's
how
the
help
chart
is
structured
today
and
there
that
that's
the
perfect
place
to
put
this
open
proxy
right.
I
can
have
one
open
proxy.
I
have
I,
have
many
agents,
one
per
node,
hundreds,
maybe
thousands
for
very
large
clusters,
but
all
it
does
is
because
I'm
using
proxy
I
only
have
a
single
connection
from
that
entire
kubernetes
cluster
to
my
backend.
So
there
are
nice
places
where
you
can
put
this
proxy
actually
in
the
future.
A
So
I
want
to
have
this
possibility
open
and
because
of
that,
the
negotiation
unfortunately
has
to
has
the
the
indication
of
the
use
of
new
capabilities
that
affect
the
serialization
of
the
websocket
of
in
the.
What
what
the
individual
websocket
means
right.
That
indication
that
the
information
about
that
has
to
be
in
the
websocket
itself,
not
in
the
headers.
C
A
Have
10
megabytes
of
a
product
of
message
that
I
need
to
send
to
the
to
the
client
or
the
opposite
direction
doesn't
really
matter,
but
I
know
that
my
particular
implementation
uses
has
a
limitation
of
the
maximum
size
of
the
websocket
like
the
AWS
API
Gateway.
That's
right,
I
know
that
I
have
to
split
this
into
chunks
of
128
kilobytes
each.
So
what
I
do
is
actually
after
serializing,
this
robot
message:
I
split,
I,
I,
literally
split
it
into
chunks
right
of
the
maximum
size
of
them
alive.
A
A
Exactly
it's
the
framing
of
the
websocket.
The
unfortunately
problem
is
the
the
there
are
implementations
which
don't
properly
implement
it.
That's
that's
I
mean
I
hate
it,
but
it
is
the
reality.
What
can
I
do
so
I'm
saying
if
we
have
to
do
this
eventually
we
decide
that
we
have
to
do
this,
I
mean
I,
don't
want
to
do
it
right,
I,
really
don't,
but
we
we
have
to
do
this.
This
is
the
way
how
we
would
do
that
right.
Yeah.
C
C
About
the
one
by
is
it
almost
feels,
like
you
know
you,
you
mentioned
the
alternate
compression
algorithm,
you
know.
Are
you
if
you're
going
to
take
a
bit
for
whether
or
not
you're
using
Z
standard?
Are
you
going
to
then
require
another
bit
for
whether
or
not
you're,
using
some
other
compression
algorithm?
And
when
do
you
run
out
of
it
fits
yeah.
A
Know
right,
so
it's
a
matter
of
how
much
we
I
mean
how
much
we're
planning
or
we're
envisioning,
how
much
kind
types
of
power
people
many
different
types
of
accessions.
We
will
need
in
the
future.
I
don't
know
nobody
knows.
Yeah
I
mean
we
can
reserve
a
bit
more,
not
just
one
bite
but
I'm
I
I'm.
Definitely,
and
it's
only
about
things
that
come
that
you
cannot
put
inside
the
product
right.
A
Every
thing
that
comes
after
the
the
serialization
is
done
can
be
inside
the
product,
and
hopefully
that
is
going
to
be
the
majority
of
new
functionality
that
we
have
to
open,
I,
hope
so
sure
there
are
things
that
you
can't
put
inside
there
and
those
are
the
only
two
examples.
I
can
come
up
with
it's
the
the
compression
algorithm
and
the
continuations,
the
fragmentation
yeah.
Maybe
there
is
something
else,
I
don't
know
right
and
and
how
many
different
compression
algorithms
are
going
to
support.
C
It
almost
it
almost
feels
like
this,
isn't
a
separate
you
know,
protocol
on
a
protocol
stack
that
you
know
should
be.
You
know,
implemented
independently
and
op-amp
operates
on
top
of
that
stack,
which
then
allows.
A
A
Right
right,
it's
an
abstraction
layer
that
we
almost
avoided,
because
we
say
that
it's
the
exact
one-to-one
mapping
between
product
messages
and
websocket
messages.
But
if
we
are,
if
we're
now
discovering
that
there
can't
be
an
exact
mapping,
then
you're
right,
it's
an
additional
protocol
layer
it.
It
is
what
it.
A
But
I
mean
that
possibly
I
I
don't
think
we
should
be
proposing
a
standard
for
that.
Well,.
C
A
So
I
think
there
are
generic
protocols
which,
like
like
what
you're
describing
they
over
for
operating
over
the
websocket.
They
also
allow
to
specify
the
encoding,
I
believe.
What's
the
name
of
that
thing,
womp
was
something
that
could
spell
start
with
the
W
from
the
websockets
I
think
there
are
things
like
that
they
likely
are
significantly
more
complicated
than
we
need
right,
so
I
don't
actually
want
to
do
that.
A
C
C
Well,
I
mean
I'm.
Just
thinking
out
loud,
I
haven't
done
any.
A
Research
you're
right,
I,
mean
you're,
saying:
let's
not
invent
our
own
right.
If
there
is
something
that
already
exists,
why
why
are
we
not
using
that?
I
am
not
aware
of
anything
that
is
as
minimalistic
as
what
I'm
proposing
right
sure,
I'm
aware
of
something
that
is
a
transport
layer
on
top
of
wave
sockets
which
allows
you
to
to
I
believe
specify
the
the
encoding
of
the
message
itself
stuff
like
that
right.
A
So
what
the
the
way
that
you
would
approach
a
generic
transport
mechanism
built
on
top
of
wave
sockets
I,
think
something
like
that
exists
right.
The
the
compression,
the
the
some
the
original
metadata,
essentially
right,
something
that
you
would
could
think
of
being
necessary,
I'm
saying
in
our
particular
case,
it's
likely
an
Overkill
right.
Probably
we
don't
need
all
of
that,
but
that's
a
that's
a
valid
question.
A
So
that
because
I
know
you
have
deployments
and
I
wanted
to
introduce
it
in
a
way
that,
for
you
it's
easier
to
to
detect
that
the
new
header
is
not
yet
used
and
that's
what
I
try
to
achieve
here
right,
I,
don't
think
if
we
choose
some
other
implementation,
we're
going
to
succeed,
data.
C
Yeah
compatibility
front
we've
basically
just
decided
that
we
are
going
to
require
agents
and
the
edge
management
platform
to
be
updated
at
the
same
time.
But
it's
not
it's.
It's
really
difficult
to
with
the
way
the
breaking
changes
in
the
part
of
our
structure
I.
C
You
know
our
Market
penetration,
but
it's
I,
I
we've
we've
we've
sort
of
decided
that
we
we're
eager
to
get
to
you
know
op
amp,
1.0
and
yeah.
A
C
Understand
update
both
our
our
collector
and
our
platform
and,
and
hopefully
you
know,
never
have
a
breaking
again
but.
B
C
B
A
B
A
Probably
yeah
I
would
say:
maybe
yeah,
maybe
we
don't
need
it
either.
I
agree
with
you:
it's
not
a
strong
argument.
Neither
of
those
is
a
strong
argument.
It's
very
likely
that
we
will
never
need
to
implement
the
fragmentation
and
we
will
never
need
to
implement
any
other
compression
algorithm.
I
I
was
just
pointing
to
some
possible
examples
of
why
and
how
we
would
use
this
header
why
it
would
be
needed.
It's
kind
of
a
way
to
I,
don't
know,
potentially
allow
the
the
extension
of
this
sort
right.
A
B
A
So
there's
two
parts
to
the
compatibility:
Story
one
is
interoperability
on
the
wire
on
the
network
level
and
the
the
backwards
compatibility
of
the
apis
that
we
Implement
I
am
a
lot
more
worried
about
the
interoperability
on
the
wire
and
about
introducing
the
changes
there
in
a
way
that
doesn't
break
compatibility
with
old
implementations,
then
I'm
worried
about
the
API
compatibility.
Api
can
probably
I
mean
it's
fine.
We
can
introduce
V2
of
your
pump
client
API
all
of
the
server
but
I.
That's
okay,
I!
Don't
see
a
big
deal.
What's
the
big
deal
with
it?
A
That's
fine,
but
interoperability.
If
you
have
deployed
thousands
potentially
millions
of
Agents
out
there
Andy
your
customer
just
doesn't
want
to
do
upgrades.
You
can't
upgrade
your
server
anymore
and
that's
a
problem
so
and
I
don't
want
to
end
up
in
a
situation
like
that.
I
want
to
make
sure
that
whatever
we
up
to
the
protocol
can
be
done
in
a
way
that
doesn't
require
you
to
upgrade
your
entire
network
at
once
in
a
log
step.
That's
what
I
want
to
avoid!
A
C
And
I
think
as
long
as
we
use
protobuf,
you
know
compatibility
semantics
of
not
reusing
indexes,
not
changing
it.
A
C
A
A
look
you're
right.
Yes,
that
gives
us
a
lot
I'm,
just
trying
to
think
of
other
possibilities
that
are
not
covered
by
that
mechanism,
and-
and
this
is
the
only
thing
that
I
could
come
up
with
it's.
Essentially,
how
do
you
move
from
the
product
buff
to
a
websocket
message?
The
red
part
is
I,
believe
it's
it's
it's,
because
it's
a
precise
and
exact
match
you.
You
have
no
flexibility
at
all
there
to
change
anything
we
commit
to
it
essentially
right.
A
We
say
this
is
the
only
way
if
you
want
to
make
any
changes
to
that.
That
essentially
I
mean
yeah.
You
could
try
to
do
the
negotiations,
but
it
won't
work
with
the
proxies,
as
I
said.
So.
Essentially
it
would
be
a
major
change.
In
my
opinion,
it
would
be
a
different
protocol
version
and
you
would
have
to
upgrade
your
your
network
at
once,
right
or
or
not
at
once,
but
you
have
to.
B
A
B
A
C
A
A
C
I
think
it's
a
good
example
of
like
another
way.
We
might
want
to
use
this
in
the
future,
but
yeah
if
the
only
things
we
have
right
now
are
compression,
which
we
don't
think
is
you
know,
is
a
good
example,
but
maybe
not
necessary
and
and
message
fragmentation,
which
specific
is
very
specific
and
potentially.
A
Can
Can,
you
guys,
maybe
maybe
think
about
this
offline
and
see
if
you
can
come
up
with
other
examples
of
where
any
sort
of
additional
header
or
something
like
that
would
be
necessary.
Any
other
new
feature,
not
the
compression,
not
the
fragmentation,
but
something
else
where
we
need
to
break
that
that
much
of
a
product
messages
and
websocket
messages.
Somehow,
if
you
can
think
of
something
else,
maybe
that's
that's!
That's
that's
what
we
can
be.
C
You
know
in
in
our
in
our
bindsight
implementation
we
added
out
of
the
op-amp
version
header
that
we
checked
for
and
it
and
we
do
that
at
the
connection
and
as
as
Sean
Sean
noted,
it's
important
yeah.
C
But
we
do
that
specifically
because
we
know
that
we
won't
be
able
to
unmarshall
the
protobuf
or
or
even
worse.
We
are
able
to
Marshal
the
Proto
buff,
but
the
fields
we
thought
we
had
are
totally
different:
yeah
yeah.
So.
C
Exactly
that
was
the
only
thing
we
needed
specifically
in
yeah
I.
Think
if
you
can,
if
you
can
rely
on
on
marshaling,
and
we
can
be
consistent
about
the
part
of
our
consistency,
then
we
can
add
any
number
of
of
fields
and
capabilities.
Right,
I
mean
I,
think
you're
right
things
like
anything
before
on
marshalling
any
kind
of
fragmentation
or
compression.
Anything
that's
dealing
with
it
before
the
actual
on
Marshall
is
is
where
you
would
need
something
like
this,
but
I
don't.
A
C
Foreign,
okay,
so
think
ing
about
stable.
There's
this
and
there's
the
frame
issue
that
I
I
I
I
did
a.
A
C
A
C
C
B
C
1.0
and
yeah
I
I
would
like
to
remove
it.
The
the
issue
is
that
you
know
initial
collectors
didn't
have
batter,
and
so
the
only
way
to
tell
if
they
were
running
a
newer
version
was
if
they
they
introduced
the
header,
but
we
might
have
moved
past
those
older
agents
at
this
point
that
we
can
safely
get
rid
of
it.
B
C
So
so
we'll
do
some
thinking
offline
on
this,
but
I
think
when
this
is
resolved
or
are
we
what
else
do
we
need
to
to
get
to
stable
or
or
what?
What
are
we
thinking
in
terms
of
timing
and
process.
A
I
guess
the
one
important
decision
we
need
to
make
is:
did
enough
people
see
the
spec
and
or
we
need
it
to
be
more
widely
circulated.
Did
we
get
enough
feedback
right?
That's
that's.
How
I
would
decide
whether
we
actually
label
it
as
a
stable
or
without
I
I.
Don't
trust
my
own
ability
in
isolation
to
make
the
decision
of
saying?
Oh,
this
is
a
great
specification.
Let's
make
a
label
and
release
it
more
and
the
only
way
I
know
is
of
having
more
yeah
more.
B
A
pretty
clever
guy
to
guns,
but
I
think
I
think
what,
for
me
to
feel
confident
is
to
see
it
and
act
like
honestly
Andy
if
you
can
remove
the
header
on
the
versions
right
that
tells
like
that
is
like
the
ultimate
indication
right
now,
I'm
truthfully
here
like
that's
for
me,
it's
like
a
does.
It
actually
work
like
is
it
robust?
Is
it
yeah
proof
is
in
the
pudding?
B
B
If,
if,
if
we
can
all
be
on
the
same
page,
there
I
think
that
is
the
perfect
indicator
that
it
can
go
stable.
So.
A
I
guess
one
other
important
thing
that
we
need
to
do
is
explain
our
stability
story.
What
is
it
that
we're
promising?
It's?
Not
just
the
label
promises
come
with
that
label
right.
What
exactly
is
that
that
we're
guaranteeing
that
we
want
to
and
what
we're
saying
that
we
may
do
right,
so
that
needs
to
be
clearly
specified
somewhere
in
this
repository
in
the
spec
or
somewhere
else
right
and
then
I
mean
never
say,
never
that
we
may
discover
things
that
we
need
and
which
don't
feel
into
the
compatibility
story.
A
A
A
B
B
A
A
A
But
again
I'm
fine
with
that.