►
From YouTube: 2021-12-16 meeting
Description
No description was provided for this meeting.
If this is YOUR meeting, an easy way to fix this is to add a description to your video, wherever mtngs.io found it (probably YouTube).
B
A
D
I
just
wanted
to
quickly
discuss.
I
don't
want
to
use
too
much
time
because
of
the
other
more
important
things,
but
this
just
I
just
saw
this
in
the
cloud
events
spec.
So
someone
from
I
think
he
works
at
the
google
sdk
google
cloud
sdk.
He
started
some
discussions
around
this.
So
in
the
cloud
events
that
distributed
tracing
extension
that
we've
been
discussing
for
some
time.
D
There
is
also
a
header.
So
this
this
one,
the
cac
trace
parent,
is
apparently
everything
that
you
put
in
extensions
there
day
forward.
D
For
example,
this
was
in
the
case
for
the
go
sdk
that
this
person
opened
the
ticket
forwards,
this
header
and
he
he
got
confused
because
he
was
expecting
to
have
the
normal.
The
standard
w3c
trace
parent
header
propagated
and
he
he
more
or
less
asked
how
customers
could
use
the
sdk
and
and
get
property
trace
propagation
working.
D
So
I
I
explained
to
him
and
touched
what
we
were
doing
and
so
on,
but
but
then
I
looked
a
little
bit
at
the
code
and
so
on
and
and
and
I
think
in
fact,
the
goal
of
this
of
this
header
was
that
it
would
contain
the
the
trace
context
that
you
initially
append
to
this
extension
and
it's
the
one
that
we're
using
to
like
decr.
D
It
will
be
the
create
context
that
we
we
talk
here,
so
it
would
so
you
would
put
the
you
would
populate
this
extension
with
the
create
context,
and
then
the
sdk
would
would
read
that
from
the
extension
and
populate
this
header
and
then
propagate
when
you
send
the
request,
for
example,
vhtp.
C
D
That's
exactly
how
that's
intended
yes,
so
I
I
just
brought
it
up
here
because,
as
we
as
we
discussed
the
propagation
and
how
we
will
append
the
creation
creation
context
in
the
message
metadata
or
some
something
like
that,
so
I
think
this
will
be
pretty
much
the
same
as
we
have
to
do
in
cloud
events
as
well,
because
we,
we
probably
shouldn't,
require
people
to
to
yeah
like
deserialize
the
the
payload
to
in
order
to
to
read
the
create
context
and
this
c
cloud
events,
header
yeah,
might
be
the
way
that
that
is
used.
D
B
Yeah,
you
should
so
I
mean
the
goal.
The
goal
of
cloud
events
here
is
to
to
to
have
metadata
is
for
you
to
not
having
cracked
the
message,
if
you're
using
binary
mode
and
to
still
have
a
distinction
between
something
that
is
cloud
event,
and
that
is
not
cloud
event.
So
you
should.
You
should
consider
that
field
as
a
as
content
of
cloud
of
the
cloud
event,
and
so
therefore,
it's
automatically
an
end-to-end
relationship
between
the
publisher
of
the
event
and
the
consumer
of
the
event
without
any
of
the
stuff
in
the
middle.
B
So
that's
that's
really.
The
intent
of
the
great
context
yeah
and
the
the
it
leaves
what
it
leaves
room
and
that's
by
intent
for
the
normal,
transparent,
trace
state
that
is
then
used
by
the
by
the
transport.
B
And
what
we're
trying
in
cloud
event
is
we
try
to
stay
stay
out
of
the
way
of
transport,
so
all
the
normal
we're
trying
to
avoid
clashes
with
the
with
the
normal
attributes
and
headers
that
the
transports
user
use
and
that's
why
we
have
that
that
prefix
in
aim
can
be
just
just
to
give
a
some
color,
but
in
amqp
the
the
equivalent
would
be
that
there
is
the
the
immutable
part
of
the
message.
B
App
has
a
has:
what's
called
the
the
the
the
bear
message,
which
is
the
the
core
of
the
message
containing
the
application
properties
and
the
properties
of
the
body?
No
intermediary
can
modify
it.
So
if
you
put
trace
parent
and
trace
into
the
application
headers
that
will
be
the
the
end
to
end
relationship
and
then
it
would
use
an
mqp,
the
message
property.
B
The
message
the
message
annotations,
which
then
provide
you
with
a
way
to
go
and
propagate
that
through
the
infrastructure
and
also
modify
it,
and
that's
also
how
the
w3c
mkp
mapping
for
open
tracing
already
states
that
so
so
that's,
if
that's
the
equivalent
of
that
here,.
A
Yeah,
that
makes
sense,
because
I
think
here
in
this
issue
like
there
isn't
there's
a
concern
that
the
trace
parent
header
is
not
arriving
or
available.
I
think
that's
actually
not
as
common
as
part
of
cloud
events
I
mean
in
this
regard.
It
would
be
that
would
be
the
responsibility
of
the
http
client
instrumentation.
Exactly.
D
With
this
person,
I
clarified,
because
I
think
he
he
he
wanted
to
have
like
he,
he
he
wanted
to
have
the
the
trace
to
be
propagated,
http
trace
propagated,
but
I
I
I
explained-
I
think
he
understood
now
that
it's
a
cross-cutting
center
has
nothing
to
do
with
with
cloud
events.
Sdks
and
as
long
as
your
http
client
is,
is
also
instrumented
with
with
hotel.
Then
the
proper,
proper
propagation
will
work,
and
I
pointed
him
out
to
the
to
the
to
the
go
sdk
where
we
implemented.
D
Where
implemented
the
the
propagations
like
the
transport
propagations
there,
and
he
also
yeah.
He
also
read
the
the
pr
that
we
have
in
the
hotel
spec
about
the
cloud
events
things.
D
D
I
have
this
pr
open
also
in
the
cloud
event
spec
to,
as
we
discussed,
to
link
the
two
together
to
link
the
hotel
spec
with
the
cloud
event
spec
and
yeah,
as
it
is
now
this
this
this
header
is,
is
removed
because
I
removed
from
from
from
the
existing
text
there
until
we
until
we
find
out
how
actually
this
is
gonna
work
yeah.
D
But
I
think
I
think
this
is
it's
to
be
probably
defined
as
we
as
we
go
with
this,
because
we'll
have
to
find
a
way
to
propagate
in
in
the
messages
clemens
was
saying
and
and
and
when
they
use
http
as
well.
So
what's
your,
what
do
you
think
is
misleading
sorry,
I
didn't
get
that.
What
do
you
think
is
missing?
B
Because,
because
in
the
cloud
of
in
the
condiment,
spec
you're
only
defining
extension
and
that
extension
is
defining
the
transparent
trace
state
headers
for
inclusion
in
the
cloud
event,
and
that
spec
is
the
extension,
spec
is
only
for
what's
going
into
the
cloud
event
it
is.
It
is
unrelated
to
http.
D
Right,
buddy
but
right,
but
but
the
extension
there
in
the
original
text
that
there
had
some
like
example,
and
then
it
showed
the
c
transparent
area
and
that
by
looking
at
some
other
other
sdks,
apparently
every
extension
that
you
add
to
the
event
then
turns
into
a
header
with
this
prefix,
so
it.
If,
if
this
is
the
case,
then
I
think
we
need
to
clarify
why
this
is
there
and
because
why
there
will
be
transparent
and
c
transparent.
That's
why
the
person
here
got
confused
yeah
and.
B
This
is
something
perpetual
that
we
had
and
we
just
need
to
go
and
clarify
in
that
spec
that
this
is
not
the
http
header
that
if
you
want
to
have
http
level
tracing,
you
also
need
to
specify
it
in
http,
so
lc
exactly
and
that's
and
that's
what
we
need
and
that's
also
one
reason
why,
for
you
know
the
the
the
cloud
events
sdks
are
done
by
different
teams
who
only
loosely
coordinate
and
which
is
for
better
or
worse,
and
the
the
principle
in
the
c-sharp
sdk,
for
instance,
is
that
we
don't
encapsulate
the
transport
such
that
you
get
to
play
with
all
the
transport
knobs.
B
However,
however,
you
want
so
that
you
can
go
and
set
the
http
headers
as
you
need
them
without
them.
Being
you
know,
access
to
the
http
client
being
shadowed
by
the
sdk
if
the
gold
sdk
doesn't
know
how
to
do
this,
that's
a
bug.
D
Yeah,
no
it
it.
As
far
as
I
know
it
does.
I
I
looked
at
the
c-sharp
sdk,
for
example,
and
and
it's
it's
it
just
offers
offers
you
like
a
way
to
create
events
like
as,
as
it's
specked
out
right.
It
doesn't
have
offer
any
any
wrapper
around
any
clients
or
anything,
and
you
can
use
any
http
client
that
you
want
to
irresponsible,
and
I
was
discussing
with
the
js
maintainer
as
well
on
the
slack
and
apparently
there
is
the
same.
They
don't
offer
any
any
wrap
or
anything.
D
So
so
the
the
the
user
is
responsible
for
for
doing
all
these
things,
which
makes
it
complicated
right
because
in
the.
B
It
was
the
so
the
goal
of
this
of
the
of
the
condense
is
the
case
is
to
give
you
to
provide
the
basic
tooling
with
you
know
and
and
the
pointy
things
are
showing
up,
because
someone
who
then
built
something
that's
a
beautiful
clean
surface
on
top
of
it
will
need
all
the
pointy
things.
So
we're
not
trying
to
be
the
thing
that
is,
you
know,
smooth
and
polished,
because
this
usually
gets
embedded
in
other
frameworks
that
are
themselves
aiming
to
be
smooth
and
polished.
B
So
we
just
want
to
go
and
provide
the
raw
power
to
those
framework
framework
folks
and
not
obscure
anything.
B
The
go
sdk
has
a
bit
of
a
different
philosophy
and
that's
you
know
their
their
choice,
but
if
you
don't
have
you
feel
blocked
in
having
you
know,
setting
both
of
those
headers
the
ce
level,
one
and
the
and
the
http
level
one,
then
you
should
raise
that
with
them.
It's
I.
I
would
consider
that
a
blog.
D
Yeah,
I
think
the
the
goal
is
decay
it
it
it
doesn't.
So
the
the
confusion
for
this
person
was
that
it
was
not
setting
the
gaussian
cable
was
not
set
in
the
transparent,
which
is
correct.
D
It
shouldn't
set
because
it's
it's
not
not
related
to
it,
but
it
was
setting
the
c
transparent
if
there
was
an
extension
yeah
and
then
he
wanted,
and
then
he
he
got
broken
trace
because
of
course
it
his
it
kind
was
not
propagate,
so
it
was
not
working,
and
then
I
explained
to
him:
that's
that's
as
intended
and
it
works
like
that
and
then
I
think
he
got
it,
but
but
the
ce
transparent
is
is
still
confusing
there.
D
D
This
c
transparent
header
again
because
I
removed
from
the
example
there
there
is
no
mention
yeah
and
and
like
one
one
last
thing
is
that
I
was
also
talking
with
the
js
maintainer
of
the
goa
sdk
with
the
cloud
defense
sdk,
and
he
I
think
he
read
the
the
current
the
current
pr
in
the
in
the
hotel
spec
about
the
semantic
conventions,
and
he
also
was
concerned
and
army
also
commented
out
in
the
pr
that
we
have.
D
I
have
the
paragraph
saying
that
what
more
or
less
the
sdk
should
have
like
handlers
and
so
on
to
to
make
it
easy
for
creating
the
process
span,
and
he
was
he
was
against
this
js
maintain
it
was
against
because
he
said
like.
I
can't,
because
the
way
like
the
way
the
sdk
works
here,
it's
it's
not
really
possible,
and
so
on
so
my
mind
also.
D
B
How
it
relates
to
transport
and
just
clarifies
that
ce
transparent,
as
it
shows
up
or
the
trace
parent
attribute
of
the
cloud
event,
is
distinct
from
the
trace
parent
header
that
you,
the
transparent
header
that
you
will
find
in
http.
Those
are
different.
They
night
in
the
first
on
the
first
hop
contain
the
same
value,
but
one
is
immutable,
end
to
end
yeah.
They
will
never
contain
the
same
value,
that's
impossible
and
that
just
needs
to
be
explained.
B
D
Yeah
sure
yeah,
the
part
was
confusing.
Was
that
was
saying
this
yeah,
but
they
should.
They
can
be
the
same.
They
cannot
be
the
same
because
if
we
go
this
route
now
that
we
always
create
the
crate
span
and
then
if
you
have
auto
instruments
that
will
create
another
one,
so
they
they
will
never
be
the
same.
D
But
okay
I'll
see
what
I
can
well.
I
can
try
to
explained
there,
but
I
just
wanted
to
bring
it
out
because
this
header
there,
however,
we
define
the
name
of
it-
will
be
the
thing
that
we
probably
will
have
in
our
messages
semantic
convention
somehow
right
because
it
might
be
similar
or
might
be
the
same
or
not
sure.
E
I
guess
I'm
just
wondering
if,
if
it
only
goes
in
as
ce
ce
trace
parent,
would
the
transport
have
to
know
to
look
for
ce
trace
parent,
which
sounds
like
you?
Don't
want
the
transport
to
know
what
it's
transporting?
No.
A
E
D
Yeah,
so
that's
what
exactly
so
that
that
is
what
we
were
saying
that
we'll
have
two
distinct
layers
of
a
trace
and
the
trace.
The
standard
trace
parent
will
be
the
the
the
transport
layer
and
then,
via
this
via
the
c
transparent.
The
receiver
of
the
event
will
create
the
process
span
or
receive
spam.
However,
we'll
define
and
then
to
to
be
able
to
construct
this
other
layer
of
the
of
the
trace,
then
it
will
use
the
c
transparent,
not
the
the
trace
parent
from
the
w3c.
D
A
I
think
that
in
the
end
depends
on
like
the
how
the
in
how
the
application
is
instrumented.
I
think
that's
not
something
that
we
can
specify,
but
one
example
could
be
that
yeah,
you
create.
You
create
a
cloud
events
message.
You
put
the
current
context
into
the
ce
trace
parent
context
and
then
maybe
this
operation
is
done
and
then
you
send
the
card
events
message
via
http
and
this
context
the
current
context,
and
that
goes
into
this
trace
parent
for
http-
might,
for
example,
be
a
sibling
span
of
of
the
create
context.
A
D
Yeah
in
in
my
examples
that
I
I
had,
I
think
I
I
had
one
example
in
the
go:
sdk
repo
with
with
the
the
http.
What
what's
what
happens
now
it?
This
will
be
a
a
a
child,
so
the
the
the
trace
parent,
so
the
http
span,
will
be
a
child
of
the
create
span
because
it
happened
before
so.
The
grade
happens
with
first
and
then
I
send
actually
the
event
and
then
it's
a
child,
but
it's
just
because
it's
it's
auto
instrumented.
The
http
client
is
not
instrumented.
A
D
It's
exactly
yeah,
and
then
I,
the
only
thing
I
wanted
to
bring
it
up
is
that
this
this
header,
it
is
defined
there
and
it
will
be
what
eventually
we
will
also
have
in
our
semantic
conventions,
because
it
will
be
what
we
will
say:
okay,
like
if
you
want
to
when
you
want
to
create
a
process
pen,
look
for
this
header
and
then
use
the
context
there,
as
as
your
as
your
remote
contacts
right
and
and
this
this
should
be
in
in
the
in
our
semantic
conventions
as
well,
because
if
we
always
will
send
this,
then
that's
what
we
need
to
look
for,
and
not
this
realize,
for
example,
the
the
the
the
distribution
three
things:
the
visualize
the
event
to
read
the
extension
yeah.
D
A
But
that
is
a
great
segue
to
the
next
point
that
I
put
here
like
the
the
some
versatile
context
publication.
I
think
actually
this
point
here,
the
consumer
instrumentation.
That
is
the
same
as
what
amir
put
here,
that
I
think
that
is
the
same
discussion.
So,
let's
maybe
just
talk
a
few
minutes
about
context
propagation
and
then
we
can
switch
to
the
to
to
this
part.
A
I
talked
the
briefly
with
clemens
this
week
and
also
great
that
he's
here
today.
Kevin's
confirmed
that
this
two
two
layer
approach
for
context,
provocation
that
we
came
up
with
makes
sense.
A
He
he
kind
of
agreed
and
the
next
question,
did
you
ask
daniel
how
to
how
to
how
to
handle
those
two
layers
in
different
protocols
I
mean
there
are
there
are
wcc
drafts
for
amqp
and
mqtt
and
kamens
is
kind
of
a
co-author
of
those
drafts,
and
what
kevin
suggested
is
that
we
basically
alter
those
drafts
or
amends
them
so
that
those
so
that
those
specs
are
able
to
support
those
two
layers
of
context
propagation,
because
currently
those
mqb
and
mqtt
drafts
here
only
support
more
or
less
one
layer
of
context
propagation.
A
Let's
see
if
I
find
that
there
are
some
interesting
parts
here,
for
example,
that
it's
possible
with
mqb
that
as
a
as
a
consumer,
you
get
two,
you
can
get
the
trace
context
in
two
different
parts
of
the
mqp
message,
so
it
seems
there's
already
kind
of
a
part
of
the
board
there
for
what
we
came
up
with
here,
but
according
to
clemens.
The
other
goal
should
be
that
we
adapt
those
wcc,
mqb
and
mqtt
drafts
so
that
we
get
support
for
those
two
layers
of
context
there.
A
In
that
way,
that
is
in
that
way,
that
will
not
part
will
not
be
part
of
this
semantic
conventions,
but
it
will
be
part
of
the
wcc,
mqp
and
mqtt
specifications,
and
I
think
one
or
maybe
the
only
open
question
that
we
have
to
answer
here
for
now
is
how
we
are
hand.
How
will
handle
http?
A
I
think
http
is
pretty
popular
and
we
should
have
some
kind
of
guidance
for
http,
and
that
is
probably
the
only
part
that
we
might
need
to
specify
here
and,
as
I
said,
for
mqtt
and
qb,
I
think
the
wcc
specifications
should
cover
that
and
for
all
other
protocols.
A
We
might
start
with
no
out
of
the
box
specification
for
now,
but
we
just
basically
give
those
those
requirements
that
we
have
already
formulated
here
and
then
it's
up
to
those
other
protocol
users
or
implementers
to
come
up
with
specifications
of
how
to
propagate
the
two
layers
of
context.
There.
E
I
like
the
approach,
I
think
that
with
amqp
it's
convenient
that
it
happens
to
have
a
almost
a
built-in
way
of
doing
this.
I
think
that
the
specification
that
exists
now
probably
didn't
have
this
in
mind.
It
was
more
that
it
was
impossible
to
to
have
a
single
place
to
to
put
a
context,
but
it's
convenient
for
other
protocols
we'll
have
to
decide
how
to
handle
this,
of
course,
but
I
think
it's
the
right
approach,
because
I
think
there
are
two
distinct
concerns
here.
A
Awesome
then,
I
will
write
this
into
this
draft
otep.
For
now.
Maybe
everybody
dinner
will
just
add
a
comment,
and
I
will
I
will
attend
then
one
of
the
next
wcc
meetings
in
january
and
see
how
yeah
how
they
feel
how
folks
they
are
feel
about.
This
idea.
A
I
think,
in
that
what
we
can
use
the
rest
of
this
meeting
for
is
that
we
talk
about
the
consumer
instrumentation,
like
I
put
up
like
some
text
here,
trying
to
summarize
what
we
discussed
in
the
last
meeting
and
also
what
amir
came
up
with,
and
I
think
the
one
open
question
that
I
tried
to
answer
here
that
was
not
clear
to
me
is
that
yeah
we
talked
about
this
receive
spam,
that
we
saw
in
all
of
amir's
army
scenarios,
and
when
I
wrote
this,
I
was
doing
one
open
question
from
edinburgh
here.
A
What
is
the?
What
is
the
duration
of
this
receive
span?
When
does
it
start?
When
does
it
end
and
what
what
the
actual
operations
does
this
receive
spam
cover,
and
I
mean
what
I
what
I
found
is
that
actually,
I
think
it
doesn't
make
sense
to
equalize
this
receive
span
here
with
this
received
state,
or
this
received
stage
that
we
came
up
with
came
up
with
here.
A
I
think
that
does
that
to
me
at
least
did
not
really
make
sense
and
to
me
it
even
seemed
that
this
received
span
also
in
amir's
scenarios,
was
kind
of
covered
kind
of
part
of
the
receive
span
and
part
of
this
process
span,
and
basically,
how
I
put
it
here
is
that
this
receives
span
covers
the
process
of
the
message
transitioning
from
the
receive
stage
to
the
process
stage.
A
So
the
idea
is
that
usually
we
have
this
receive
stage
here,
handled
by
an
sdk,
so
sdk
handles
the
receiving
of
the
message
reads
it
from
the
wire.
Maybe
maybe
does
some
pre-fetching
or
caching,
and
then
at
one
point
those
sdk
passes
the
message
on
or
the
application
kind
of
requests
message
from
the
sdk.
A
A
There
was
there
were
great
comments
on
the
pr,
so
thanks
everybody
for
reading
my
writing
and
commenting
on
it
and
to
make
this
clearer,
I
tried
to
also
put
in
yeah
this.
I
came
up
with
this
with
this
diagram
here.
Basically,
those
black
boxes
that
they
model
our
stages
that
we
have
laid
out
with
the
intermediary.
A
Then
we
have
received
with
process
and
in
receive
there's
quite
a
lot
that
can
happen
because
there's
received
from
the
wire
I'll
read
mqb
or
http
messages,
then
you
may
be
cache
messages
for
like
your
prefetch
and
cache
messages,
and
then
here
there
is
this
last
process
where
you,
it
is
last
stage
where
basic.
Basically,
you
forward
a
message
for
processing
to
the
to
this
next
process
stage.
A
So,
as
all,
as
you
said,
usually
receive
happens
in
the
sdk
process,
happens
on
application
on
the
application
layer-
and
there
is
this
there
is
this
point
in
time
where
the
message
basically
passes
over
from
this
stage
to
the
other
stage
and
yeah.
The
proposal
that
I
came
up
with-
and
I
think
it's
consistent
with
what
amir
came
up
with-
is
that
there
are
this.
A
The
process
of
passing
this
message
over
that
we
cover
this
process
by
this
receive
spam,
whereas
I
think
receive
is
not
not
a
good
name
for
this,
so
I
guess
we
should
try
to
come
up
with
a
different
name,
because
this
receives
span
you
one
might
suggest
that
it
covers
the
receive
stage,
which
is
not
the
case
here,
so
it
just
covers
one
small
part
of
this
receive
state.
A
So
probably
we
should
have
another
name
for
this
span,
but
at
least
for
my
thinking,
this
model
makes
sense,
also
because
it's
it
give
a
it
gives
us
like
a
common
denominator.
That
is,
I
think,
applicable
to
almost
all
scenarios
that
we
have.
We
will
always
have
this
scenario
where,
basically,
this
the
message
passes
from
the
receive
layer
to
the
process
layer,
either
in
single
message
cases.
It's
just
a
single
message
cases,
it's
just
a
single
message
in
batch
cases.
A
So
here
on
the
process
side,
basically,
there
could
be
spans
parented
or
linked
to
this
receive
span
as
needed,
and
also
on
the
receive
side
like
there
could
be
basically
spans
on
the
transport
layer
that
are
basically
happened
before
this
receives
span
and
are
parented
or
linked
to
this
receive
span.
A
F
Yeah,
I
have
a
couple
of
comments
here.
So
the
first
one
is
I've
done
some
research
on
how
like
the
sdk
api
looks
like
for
different
systems,
and
I
think
we
need
another
separation.
There
are
push
based
things
where
you
receive
something
out
of
blue.
Maybe
it's
an
http
hook
or
something
there
are
things
where
you
pull
right
and
this
essentially
look
different
and
we
would
have
to
provide
a
different
guidance
for
them.
F
And
it
would
be
very
useful
to
map
this
to
some
code.
I
like
this
diagram,
I
like
it
and
it
makes
sense,
but
I
still
I'm
not
sure
I
understand
fully
how
how
it
maps
to
the
real
application.
A
A
Js-
and
here
we
basically
see
we
have
here
the
consumer
and
we
trust
which
is
register
callback
here
in
in
this
first
example,
it's
like
a
callback
for
a
single
message
that
is
called
basically
for
each
method,
each
message
that
is
received-
and
here
it's
a
callback
for
a
badge-
and
I
think
how
that
would
map
to
those
previous
diagram
diagram-
is
that
this
callback
operation
like
this
when
each
each
message
is
called
by
the
by
the
sdk
in
that
regard,
because
the
callback
is
called
by
the
by
the
consumer.
A
A
It's
up,
then,
to
the
application
to
the
application
developer
like
who
writes,
who
implements
this
callback
here
to
create
processbands
and
he
gets
basically,
the
inside
is
callback
like
the
receive
span
will
be
the
current
context
and
then
inside
this
callback,
like
the
the
the
developer,
writes,
this
callback
can
then
add
processbands,
and
if
the
processing
happens
inside
this
callback,
then
they
could
be
directly
parented
to
this
receive
spam.
If
process
had
processing,
happens,
asynchronously
and
and
happens
like
after
this
callback
ends,
for
example,
message
is
restored
somewhere
else
and
then
processed
later.
A
Then
then,
those
process
bands
that
are
created
there
could,
for
example,
be
linked
to
this
receive
span.
So
it's
kind
of
we
have
this.
As
I
said,
this
common
denominator
of
this
receive
span.
A
That
is
also
linked
to
the
creation
context,
but
then
how
the
process
bands
are
created
and
correlated
to
this
receive
span
that
is
then
heavily
dependent
on
on
on
what
scenario
we
have
here,
whether
it's
kind
of
a
synchronous
or
asynchronous,
or
whether
there
are
kind
of
operations
related
to
distinct
messages
or
whether
there
is
just
yeah
generic
operations
like
db
rights
and
reads
that
are
not
related
to
single
messages.
I
think
it
can
all
be
modeled.
F
A
F
A
Yes,
we
would
need
to
define
it
because
yeah
it's
basically.
The
question
here
is
who
who
initiates
this
receive
operation,
which
we
still
have
to,
I
think
find
another
name
for
who
initiates
this
operation?
Is
it
kind
of
a
push
or
pull?
Is
it
like
the
sdk
quote-unquote
to
initiate
the
operation,
or
is
it
the
application
who
initiates
this
operation?
A
This
is,
I
think,
that's
that's
a
good
point.
That's
something
we
need.
We
need
to
work
out.
I
wonder
I'm
here.
Did
you
come
across
those
those
differences
in
in
your
examples.
G
Yeah,
actually,
I
want
to
share.
Last
week
we
had
a
discussion
and
then
I
had
another
discussion
with
ludmila,
which
helped
me
consolidate
my
thoughts
on
this
issue.
G
So
I
think
that
in
current
specification,
at
least
from
my
perspective,
like
I
used
to
think
of
processing
as
anything
that
is
related
to
a
single
message
and
receive
as
something
like
a
container
for
the
entire
batch
and
that's
the
way
I
look
at
it
currently,
so
it's
very
convenient,
but
when
you
think
about
it,
actually
the
receiver
like
there
are
two.
G
Purposes
for
it
like
one
of
them,
is
to
describe
the
the
the
networking
or
the
operation
of
going
to
the
server
and
they're
receiving
a
better
of
messages.
G
Maybe
there's
some
networking
involved
and
stuff
like
this,
and-
and
this
is
very
symmetrical,
I
think,
with
the
publish
operation
because
and
publish
our
like
they,
they
sound
like
two
exact
roles
of
of
the
same
okay,
so
women,
I
kind
of
stuck
with
the
english.
G
I
hope
you
can
understand
me
well
but
like
this
is
one
role
of
the
receive
to
describe
the
networking
the
going
to
the
server
and
fetching
the
messages
and
the
second
role,
which
I
think
correlates
with
what
you
were
wrote
in
your
autop
and
and
with
this
s,
picture,
which
I
really
like
is
like.
Like
a
container
for
the
like
saying,
okay,
I
have
a
batch
of
things.
G
I
don't
want
to
create
a
process
span
for
them,
because
process
should
correlate
to
a
single
message,
but
still
I
want
a
way
to
to
group
all
these
operations
under
a
single
span
and
say
this
is
a
batch
of
messages
that
are
all
processed
together
or
where
they're
all
handled
together
as
a
batch,
and
I
just
want.
C
My
my.
F
G
Sorry
about
them
you're
getting
stuck
so
so
the
receiver,
it
has
two
purposes:
the
networking
and
the
batching
operation,
and
after
talking
with
ludmila,
which
offers
another
approach
is
to
separate
those
two
roles.
So
we'll
have
like
something
to
describe
the
networking
and
something
to
describe
the
batching
in
in
the
application
part
sdk
part,
so
it
for
me.
It
kind
of
makes
sense.
I
still
not
sure
about
all
the
fine
details
like
how
it
would
look,
but
it
made
more
sense
to
me
than
what
they
showed
last
week.
A
Yeah,
I
think
that's
what
I
tried
to.
I
think
you
can
interpret
this
diagram
in
this
way,
basically
have
the
the
the
transport
operation
of
receive.
That
is
here.
Basically,
you
read
the
message
from
the
wire-
maybe
there's
some
caching
prefetching
that
maybe
maybe
not,
but
I
think
you
me
or
in
my
opinion
it
makes
definitely
sense
to
separate
those
two
receiving
from
the
wire
and
then
actually
the
the
forwarding
to
the
application
layer
and
also
in
in
the
process
of
this
forwarding
to
the
application
layer.
I
think
that
is
your
point.
A
That's
also
processed,
that's
also
the
point
where
we
basically
can
handle
this
whole
the
whole
patching
problem,
because
here
then,
basically
the
match
messages
get
aggregated
and
either.
I
just
think
messages
get
passed
on
or
like
a
batch
gets
passed
on
here
and
that
basically,
we
have
covered
by
this
this
man
here
that
we
still
need
to
find
here
a
better
name
for,
but
we
basically
are
split
up
this.
This
receive
into
do
into
two
different.
A
Two
different
operations,
like
the
one,
basically
are
the
transport
layer
operation,
which
we
probably
will
not
cover
by
the
first
version
of
the
conventions
and
then
basically
a
separation
that
interfaces
with
the
application
layer
that
we,
I
think,
is
a
minimum.
I
think
that
we
need
to
cover,
and
the
other
is
still
then
an
open
question
here.
What
luke
miller
brought
up,
which
I
think
we
or
I
or
we
need
to
need
to
think,
need
to
think
more
about
this
yeah
better?
How
does
this
work
for
push
models
and
for
pool
models.
F
This
sounds
like
a
push
model,
or
maybe
we
should
call
it
prefetch
model
or
something
right,
yeah
and
for
for
poo
pole
model.
There
were
other
big
problems,
but
we
maybe
we
don't
have
to
discuss
them
right
now.
D
Could
we
call
the
receive
forward,
then
this
pen
does
it
does
it?
Does
it
make
sense
to
call
it
forward
spin
because
that's
what
it
is
doing
or
like
at
this
point,
the
one
that
you
have
in
orange
at
this
point,
you
already
did
the
like
it
received
from
the
wire
and
then
maybe
you
you
wait
for
some
some
time
to
do
some
pre-fetching
or
some
caching.
D
Until
you
have
some
number
of
messages
and
then
at
the
end
you
forward
right
and
then
in
this
band,
it's
where
we
will
have,
for
example,
the
number
of
of
messages
right,
but
we
are
there
that
we
are
passing
if
we
have.
D
A
Yeah
I
mean
forward
is
one
option
I
think
duane
suggested
a
a
name.
That's
like
the
name
deliver.
A
I
I
I
think
what
one
needs
to
have
in
mind
here
is
that
when
we
think
about,
like
the
customer
point
of
view
like
they
have,
let's
say
a
minimal
instrumentation,
they
don't
have
the
transport
layer
instrumented,
but
they
would
see,
then
is
they
would
see
the
create
span
and
they
would
see
this
this
receive
span
or
forward
span
or
deliver
span,
and
when
you
only
have
this
minimal
point
of
view,
I
think
the
quest
for
me
is:
does
it
make
sense
that
you
have
to
create
span
and
then
you
have
a
forward
span
and
those
are
linked
together?
A
A
What
I'm
not
sure
is
whether
the
deliver
term
kind
of
is,
but
whether
this
might
be
an
overloaded
term
or
whether
there's
a
different
meaning
for
those
term
in
the
in
the
mess
in
order
messaging
jargons.
A
A
Then
I
don't
need
an
a
normal
opinion.
I
just
wonder:
if
is
the
delivered
term,
is
that
used
in
lots
of
con
lots
of
different
contexts
in
messaging
or
is
it
kind
of?
Would
they
would
they
confuse
people
by
using
the
term
delivery?
No.
G
I
want
to
ask
the
group
before
we
talk
about
this
deliverable
forward.
If
you
think
process
spends
should
always
relate
to
a
single
message
or
maybe
process
pens
can.
D
E
Messages
but
yeah,
I
I
think
that
would
be
typical
as
well.
I
don't
know
if
you'd
want
to
go
so
far
as
to
say
that
it
must
be
that
way.
I
can
imagine
people
might
exp,
might
kind
of
look
at
two
messages
and
use
a
combination
of
the
information
to
perform
an
operation.
Like
I
mean
it
seems
a
little
strange,
but
I
don't
know
if
we
should
prevent
them
from
doing
that.
If
that's
what
what
they're
doing.
F
Well,
I
can
tell
there
are
multiple
cases
where
you
want
to
receive
a
badge
and
you
want
to
process
them
together.
For
example,
you
just
listen
to
something
it
sends
you
a
firehouse
of
things.
You
cannot
process
them
right
away
and
you
store
them
somewhere
as
a
badge.
This
is
a
typical
case
for
like
many
things
in
azure,
there
are
cases
where
you
receive
a
badge
as
a
safe
of
resources.
For
example,
azure
functions
called
bill.
You
per
execution
and
people
receive
a
badge
because
it's
cheaper
and
then
they
process
them
separately.
F
So
there
are
apis
and
azure
as
the
case,
and
in
some
I
I
couldn't
find
other
examples,
but
sorry,
but
anyway,
so
there
are
cases
where
we
sdk
provide
an
api
to
receive
a
batch
and
process
a
badge,
and
it
is
maybe
less
typical
than
a
single
message,
but
we
should
have
a
convention
for
it.
E
Yeah,
I
think
I
agree
for
sure
on
the
kind
of
receive
forward
deliver,
whatever
we
name
it
that
that
that
could
be
used
for
a
batch,
and
I
guess
the
question
is
more
once
you've
got
the
batch
and
need
to
process
the
things
in.
It
is
each
thing
in
it,
processed
as
an
individual
item
or
is
the
whole
batch
or
multiple
or
parts
of
the
batch
one
process
span.
But
given
you
have
the
the
the
receive
forward
deliver
that
can
encompass
multiple
things
in
a
batch.
F
Yeah,
I
think
I
I
when
I
think
about
it.
There
are
user
scenarios
which
we
have
no
control
over
and
we
probably
can
tell
users
how
to
write
menu
instrumentation
if
we
are
trying
to
address
auto
instrumentation
first-
and
I
think
this
is
a
reasonable
goal
to
have
then
for
all
the
instrumentation
you
don't
you
don't
know
how
it's
used
right,
you,
it
doesn't
matter,
probably
well
it
matters
after,
but
we
cannot
control
anything
on
the
old
instrumentation
side.
E
I
think
I
agree
with
mueller
like
I
think
what
I
was
saying
earlier
is
that
it
would
probably
often
be
one
process
per
message,
but
I
don't
know
if
we
should
dictate
how
to
applications
how
they
should
instrument
that.
A
A
A
I
think,
what's
the
nice
thing
is
that
it
offers
the
flexibility
for
also
for
this
process
spans
to
kind
of
be
created
according
to
what
fits
best
for
the
for
the
for
the
respective
scenario.
So
it
could
be
like
a
span
for
each
message
in
the
batch
or
it
could
be
one
span
for
all
the
messages
in
the
batch,
and
I
I
think
what
we
can
do
with
this
model
is.
A
We
can
provide
this
flexibility
here,
but
still
basically
have
the
common
ground
of
this
deliver
span
that
we
will
always
have,
and
that
kind
of
can
be
used
to
link
to
the
creation
context,
but
I
think
we
should
not.
We
should
not
enforce
or
require
any
or
we
shouldn't
impose
any
limitation
on
creating
these
process
bands.
I
mean
we
might
give
some
maybe
best
practices,
but
I
think
we
shouldn't
impose
any
requirements
or
limitations.
G
G
It
can
either
be
a
processing
of
one
message
or
a
batch
of
messages
right
if
I
understand
the
conversation
correctly,
but
then
I
want
to
to
ask
what
is
the
difference
between
processing
of
batch
and
and
this
deliver
or
a
forward
span,
because
the
way
I
see
it
like,
if
you
have
a
dispatch-
and
you
like
this-
deliver
a
hispanic,
it
can
have
a
child
spends,
and
this
child
spends
day.
The
semantic
semantically
saying
I'm
doing
something
in
the
context
of
the
batch
and
not
in
the
context
of
a
single
message.
A
I
think
the
question
here
is
regarding
the
difference
is
whether
we
also
want
to
come
up
with
some
normative
language
regarding
those
process
bands-
and
I
think
then
then
it
might.
Then
it
might
make
a
difference,
because
if
you,
if
you
want
to
come
up
with
some
normative
language
regarding
the
process
bans,
then
we
might
need
to
say
okay,
you
need
to
have
a
process
ban
for
each
message
that
is
in
this
batch
that
gets
passed
over
to
the
to
the
application
and-
and
I
think
this
will
be
too
much
of
a
limitation.
A
So
I
think
we
cannot
give
any
kind
of
strict
normative
language
for
creating
these
process
bans.
But
I
think
we
can
give
some
guidance,
but
I
think
that's
mostly
then
yeah
in
the
for
the
application
developers
to
judge
how
they
create
those
process
spans.
A
Yes,
I
think
that
I
think
those
are
all
cases
that
semantic
conventions
should
allow
and,
and
they
are
they
could
be-
there
could
be
a
parent
child
relationship.
I
mean
if
the
processing
happens,
asynchronously
that
could
those
could
also
be
links
like
then
the
deliver
spam
could
link
to
the
processbands
if
the
processing
happens
asynchronously.
A
G
Db
right,
underneath
it
doesn't,
it
mean
like
this:
libya
right
happens
in
the
context
of
processing
the
bench.
A
Yes,
yes,
I
think
so
I
mean
I
would
say
I
would
interpret
it
in
a
way
that
every
span
there
is
a
child
of
this
delivery
span
is
related
to
processing
the
messages.
I
think
we
saw
this
in
your
examples
like
you
had
to
receive
span,
and
then
you
had
like
child
spans
that
were
not
related
to
a
particular
message,
but
it
were
like
database
operations
rather
operations,
and
I
think
it's
safe
to
assume
that
all
spans
that
file
spans
of
this
deliver
spans
are
related
to
to
message
processing.
G
A
I
think
in
my
understanding
you
can
put
it
that
way.
I
mean
I,
I
think
you
will
gain
additional
granularity
by
having
process
bands
separately,
but
I
think
that
is
then
something
that
you
have
to
know
as
as
your
as
the
owner
of
your
application,
I
think
when
you
instrument
your
application
and
you
don't
create
process
bands,
then
then
you
are
probably
aware
of
that.
The
deliver
span
basically
covers
the
processing
of
the
message.
Too.
I
mean
it
gets
a
bit.
A
Then,
if
you,
when
you
process
asynchronously,
like
you,
showed
in
some
of
your
examples
when
you,
for
example,
you
obtain
like
this
area
of
messages,
and
then
you
do
several
kind
of
operations
of
this
on
these
messages
outside
this
deliver
context,
in
a
for
loop
or
or
in
or
in
other
like,
like
asynchronous
operations,
but
but
I
think
that
is
then.
That
is
something
that
we
have
to
put
in
the
responsibility
of
the
application
like
instrumentor
to
come
up
with
something
that
makes
sense.
A
F
Has
I
I
have
a
question
so
I'm
a
bit
worried
that
we
are
confusing
two
different
things
here.
I
can
would
you
mind
if
I
share
my
screen
for
a
second.
F
Yeah
so
give
me
a
second
okay.
F
So
I
want
to
show
a
couple
of
examples:
did
you
see
my
screen.
F
A
F
Yeah,
so
one
of
the
examples
is
this:
when
we
call
the
receive
and
it
can
be
prefetched,
it
can
be
something
that
happens
locally
and
it
can
be
a
local
call.
So
it's
it's,
not
the
it's
a
pole
model,
it's
just
the
question
of
how
system
works,
but
in
this
case,
as
far
as
I
understand
the
this
delivery
span,
it
would
match
this
operation.
The
consumer
does
receive
from
partition
right.
Yes,.
A
F
Then
what
about
the
other
example?
So
let's
say
we
have
this
right.
This
is
the
one
that
we
basically
ignore
my
comments.
It
was
created
before
I
heard
before
this
meeting.
So
for
this
case,
the
deliver
the
delivery
span
would
match
what
happens
inside
the
callback
right.
A
F
A
Yes,
the
deliver
span.
Basically
I
mean,
as
I
would
put
it,
I
think
there
would
only
be
a
deliver
span,
but
then
yeah.
It
is
up
to
the
implement
of
the
callback
to
create
the
process
span.
Yeah.
F
Yeah,
I
agree
I'm
just
trying
to
understand
the
delivery
span.
Then
would
it
mean
that
delivers
pen
has
different
meanings
in
terms
of
application
order,
so
they
do
come
for
what
it
feels
to
me
to
different
calls,
and
in
this
case,
for
example,
the
process
event,
this
delivery
span
would
rub
the
processing
yes,
but
in
the
first
example,
it
would
only
rub
the
delivery
stage.
A
Sorry
johann
go
ahead.
No,
I
just
want
to
say
yes,
there
is
there's
a
there's.
Luke
miller
is
right.
He
puts
the
thing
off
like
some
semantic
difference.
That
is
basically
there
so
that
the
delivery
span
can
wrap
processing,
but
it
also
it
must
not
wrap
processing,
and
I
think
the
idea
of
this
deliberate
span
is
there
in
this
context.
Basically,
it's
an
operation
that
the
consumer
does
and
it
has
a
start
and
an
end,
and
basically
the
this
consumer
implementation
returns
those
in
the
first
step.
A
It
returns
those
messages
that
has
a
clear
start
and
end
that
we
can
imagine
also
in
the
second
step
it.
Basically,
it
starts
this
callback
and
it
and
when
the
callback
ends
basically
there's
also
the
start
and
from
the
point
of
view
of
the
consumer-
and
I
think
that
is,
that
is
at
least
my
first
idea
of
how
this
delivers
span
can
be.
I.
F
See
so
that,
in
this
example,
delivers
pen
would
pre.
It
would
happen
before
this
callback
right.
A
A
From
to
golo,
I
think
the
this
event
processor
client
before
they
start
the
callback
they
will
start
to
span
and
when
the
callback
returns,
the
processor
client
will
end
the
span.
F
A
A
Yeah.
Thank
you.
So
I
will
add
this
as
a
comment
to
the
pr
and
maybe
if
any
people
have
thoughts,
they
can
comment
there
and
otherwise
we
can
continue
discussion
next
week
because
we
are
already
one
minute
over
sorry
joanna
cut
you
off,
I'm
not
sure.
If,
if
I
think
we
would
still
have
some
minutes,
if
you
still
wanna.
E
I
was
just
going
to
say
that
you
know
if
we
wanted
to.
We
could
make
the
semantics
the
same
where
the
delivery
span
always
ends
and
in
the
case
of
the
asynchronous
delivery
via
callback.
You
could
end
the
deliver
span
before
you
call
the
callback,
but
then
it's
much
less
useful.
I
think
it's
more
useful
if
it
can
encompass
the
callback,
and
so
I
think,
if
we
just
define
the
two
scenarios,
perhaps
identify
them
a
different
name.
I
think
that
makes
sense
but
yeah.
E
I
think
we
can
just
discuss
this
later
offline
and
in
comments
too.
A
Yeah,
so
I
will
I
will
put
this
this
open
question
as
a
comment
to
the
pr
and
yeah,
let's
discuss
offline
or
otherwise,
let's
continue
next
week.
A
A
C
I
I
would
be
fine
with
just
having
january
13,
be
the
next
meeting
date,
but
obviously
I'm
not
the
most
active
member
of
the
group.
I've
been
dressed
as
whether
people
think.
A
I
mean
I've
that
the
meetings
are
on
the
calendar
anyway.
So
if
peop,
I
would
say
if
people
want
to
gather
and
discuss
and
and
summarize
their
findings
in
the
pr
and
in
the
in
the
in
the
protocol.
That's
okay,
but.
D
We
can
also
we
can
also
quickly
regroup
in
this
like
channel
that
someone
created
now.
A
Yes,
I
think
that's
the
best
idea.
Maybe
if
people
have
interest
meeting
an
interesting
meeting,
then
they
should
should
write
this
in
the
slack
channel
and
other
people
can
respond
if
they
want
to
meet
and
otherwise
yeah.
Let's
make
a
break
till
january
13th.