►
From YouTube: 2022-11-15 meeting
Description
cncf-opentelemetry@cncf.io's Personal Meeting Room
A
A
One
is
a
reference
to
an
open
Telemetry
discussion
about
photobops
in
the
API.
B
Okay,
I
see
I
see
there
is
already
agenda
for
for
future
for
a
future
meeting
on
29th.
B
Well
so
my
first
impression
here
without
looking
too
deep
into
the
issue,
is
that
well,
since
the
collector
is
actually
the
main
our
main
use
case,
we
should
probably
follow
what.
A
I
think
that's
the
right
Spirit.
However,
the
I
think
there's
a
big
difference
in
that
the
op-amp
spec
calls
out
protobuf
as
the
communication
layer.
It's
actually
part
of
the
protocol.
A
It's
the
encoding
of
the
data
set
on
The
Wire,
so
I
think
it's
different
with
the
collector
and
that
the
collector
otlp
receiver
and
exporter
optional
components
that
don't
aren't
fundamentally
required
by
The
Collector.
A
You
know
the
collector
uses
P
data
internally
to
to
pass
data
through
the
pipeline,
but
it's
not
explicitly
protobuf
until
it
reaches
a
state
where
it
needs
to
be
encoded
as
or
decoded
from
or
to
protobuf.
You
know
TLP
so.
A
Little
bit
different,
if,
if
we
were
going
to
change
the
op-amp
spec
to
say
something
different
about
the
encoding,
you
know
have
some
other
data
format
that
we
choose
XML
or
something
like
that.
I
think
we
would
need
to
include
the
XML.
A
You
know
it
that
would
that
would
it
would
make
sense
to
have
that
be
part
of
the
protocol
encoding
and
decoding
so
I,
don't
I,
don't
I
realize
there's
a
dependency
on
the
Generation
generation
of
the
code,
but
the
generation
of
the
code
produces
the
the
actual
encoding
that
we're
using
in
the
protocol.
A
And
I
think
every
effort
is
being
made
in
that
generation
code
to
maintain
backward
compatibility,
otherwise
using
protobuf
as
a
transport
layer.
Would
you
know
not
not
be
realistic,
so.
B
A
B
So
yeah
yeah
I
would
have
to
dive
into
into
this
and
see
what's
really
going
on
a
lower
lower
level.
I
I
haven't
been
involved
in
in
that
kind
of
things
for
for
a
while.
So.
B
Think
I
think
we
should
yeah
postpone
it
until
we
we
get
more
feedback
from
people
who
are
really
working
on
in
the
trenches
on
the
code
and
and
can
provide
some
some
new
insights
I
will
try
to
look
at
it,
of
course,
as
well
sure.
A
Then
the
other
thing,
I
added
with
PR
I,
think
I
opened
this
a
little
over
a
week
ago,
I'm
still
trying
to
find
a
way
to
manage
connection
State.
The
the
kind
of
primary
goal
is
to
connect
Beyond
connecting
function
to
the
other
callbacks
on
connecting
you
have
access
to
the
HTTP
request.
So
you
have
access
to
things
like
client
certificates
and
headers
and
other
things
on
the
request.
A
So
I
don't
know
if
the
change
in
the
pr
is
is
obvious,
but
the
basic
idea
is
that
the
first
callback
on
connecting
can
return
connection
callbacks.
So
it's
up
to
the
the
implementer.
They
could
return
the
same
set
of
callbacks
or
they
could
return
custom,
callbacks
and
and
basically
return
a
new
set
of
callbacks
per
connection
and
then
by
doing
that,
they
can
maintain
State
on
that
obstruct.
B
So,
what's
what
would
be
a
typical
use
case
for
that?
So
this
is
I
understand
on
the
server
side
right,
so
the.
A
Biggest
thing
is:
if
you
want
to
use,
for
example,
client
certificates
for
identifying
the
agent
and
for
securing
agent,
then
in
the
subsequent
on
message
calls
you
you
want
to
know
what
that
identity
was.
Do
you
have
the
agent
ID,
of
course,
but
you
don't
have
you
know
what
it
used
to
authenticate.
A
Example,
what
the
way
I've
had
to
do
this
in
Vine
plane
is
I
pass
a
header
to
the
agent
ID
header
into
on
connecting
and
now
that
lets
me
know
and
on
connecting
what
agent
idea
is
trying
to
connect.
That's
not
explicitly
part
of
the
protocol,
but
that's
that's
necessary
to
correlate
on
connecting
to
the
other
callbacks,
because
otherwise,
there's
no
shared
information
between
the
callbacks
I.
B
A
Something
needs
to
be
done.
I
I
had
a
a
separate
PR.
That's
referenced
number
143
that
I
didn't
love
personally,
so
I
wasn't
necessarily
surprised
by
feedback,
but
I
I
I
wasn't
I
didn't
like
the
idea
of
generating
a
token
that
that
linked
on
connecting
to
the
unconnected
and
then
using
that
token
to
then
manage
the
state
with
the
connection,
it
just
seems
like
you're,
you're
kind
of
handing
it
off
from
one
function
to
the
next
and
then
then
maintaining
your
state.
A
Your
in
your
own
map
on
you
know,
whereas
the
the
library
can
do
this
for
you,
it
has
the
ability,
as
you
can
see
in
the
pr
that
I
made
it's
it's.
It's
really
just
a
matter
of
passing
that
called
the
callbacks
through.
That's
it's
basically
a
local
variable,
so
yeah.
B
C
A
Anything
I,
I
I,
need
to
add
some
examples
of
of
using
it
and
and
some
tests,
obviously,
but
I
want
to
just
wait
before
going
down
that
road.
Make
sure
that
this
was
something
we
felt
comfortable
with
yeah
yeah.
A
This
simple
example
that
I
have
in
the
comment
just
stores
the
connects
at
that
time.
A
So
any
message
and
you'd
probably
just
use
it
in
logging
or
something
like
that,
but
you
would
know
when
that
how
long
that
connection
lived?
A
B
A
A
Okay,
I
think:
that's
it
I'll,
maybe
add
my
thoughts
on
the
protobots.
Just
it
being
I'll
just
add
that
to
the
dock
here,
just
that
with
it
being
part
of
this
back
I,
think
it's
a
little
bit
different
than
the
collector,
but.
C
No
I'm
I'm
fairly
new
to
this
community.
The
open,
Telemetry
I've
been
browsing
the
code
and
browsing
the
repositories
and
looking
looking
for
some
new
beginners
kind
of
issues,
so
that
I
can
contribute
to
so
yeah
that
that
that's
it
okay.
B
A
B
All
right
thank.