►
From YouTube: 2021-11-11 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).
A
B
Hello
good
morning,
hello,
good
evening:
there
you
are,
let's
give
people
a
few
more
minutes.
Maybe
let's
give
them
two
more
minutes
to
show
up
and
dial
in
and
in
the
meantime
I
will
post
the
link
to
the
meeting
protocol
in
the
chat.
So
please
add
your
name
and
add
any
item
to
the
gender
that
you
want
to
discuss.
C
A
B
Okay,
let's
get
started,
I
saw
I
will
share
my
screen,
so
we
can
see.
What's
on
the
channel
I
saw
there
is
this
point
about
instrumentation
spec
approvals.
We
can
start
with
that.
B
D
Yeah,
so
this
is
just
just
some
procedural
stuff.
Tigram
was
nice
enough
to
create
a
a
open,
telemetry
github
team
for
instrumentation.
D
We'll
probably
want
to
subdivide
this
into
subgroups
for
messaging
and
other
things,
but
I
thought
it
would
be
good
to
start
start
with
just
a
single
list.
For
now
ken
I
think
you
had
said
you
would
be
interested
in
doing
some
approval.
But
sorry,
I
didn't
know
your
github.
B
D
Either
armin
or
tigrin
can
modify
this
list
just
fyi.
I
personally
can't
modify
it.
It
requires
a
tc
member
to
modify,
but
I
will
I
will
poke
them
to
to
get
it
done
so
yeah
if
anyone
else
would
like
to
to
be
added
to
this
list.
Just
let
me
know
if
your
name's
on
it
and
you
feel
like
you,
don't
you're
not
actually
gonna
have
time
to
to
do
pr
reviews
or
approvals.
Also,
let
me
know
that's
fine.
D
D
Automatics
a
strong
word
but
yeah
we're
trying.
If
you
look
at
the
at
the
spec
there's
the
way
we
divide
the
spec
up
and
oteps,
and
things
like
that.
There's.
What
do
you
call
it?
We
use
code
owners,
code
owners
file
to
subdivide
approvers
into
different
sections,
and
so
we'll
take
this
this
group
and
apply
it
to
sections
that
are
relevant
to
to
instrumentation
related
semantic
conventions.
Stuff,
like
that.
D
This
does
require
me
to
get
off
my
butt
and
actually
complete
my
pull
request
of
reorganizing
this
spec.
Sorry,
I've
had
a
a
big
report
due
this,
I'm
finally,
finally
done
with
so
I'll
try
to
get
that
cleared
up
next
week,
but
that'll
help
us
make
the
the
code
owner's
file
a
little
bit
simpler.
E
D
A
teagan
just
made
one
group
for
now,
but
I
told
him
we
want
to
probably
want
to
to
subdivide
it
up
into
like
a
messaging
group
and
http
group
and
maybe
maybe
other
groups.
So
that's
totally.
A
D
Yes,
yes,
we
it's
just
the
way
we
manage
it
in
open
telemetry.
Is
we
like
to
assign
teams
the
code
owner
files
and
then
manage
the
teams?
It's
just
a
little
bit
less
crazy
making
for
the
admins
that
make
sense.
B
Okay,
awesome
thanks!
So
when
maybe
you
can
just
add
your
maybe
github
elias
here
in
the
protocol,
and
then
we
can,
maybe
that
can
make
sure
that
it's
gonna
be
added
to
the
messaging
group.
Instead,.
D
Yeah
yeah,
please
yeah,
please
add
your
your
github
name
there,
ken
I'll,
add
yours,
oops,
sorry.
D
D
So
you
don't
have
to
wait
for,
say
an
admin
to
to
do
any
assignments.
You
can
like
at
the
group
and
say
hey
what
do
you?
What
do
you
think
about
this?
Is
this
a
good
way
to
get
people's
attention.
B
D
Will
give
us
a
little
more
autonomy,
so
hopefully
we
can
move
a
little
bit
faster,
so
we
still
want
to
make
sure
we're
getting
at
least
at
least
some
tc
attention
and
armin
is
the
the
the
tc
member
who
said
he
would.
He
would
specifically
pay
attention
to
a
lot
of
the
instrumentation
related
stuff,
so
we
can
ping
him.
B
B
C
Yeah,
so
ludmila
actually
sent
the
pr
to
this
to
my
branch
and
we
yeah
we
discussed
together.
So
there's
some
some
changes
and
I
also
had
the
demo
that
we
discussed
to
show
as
well.
B
Awesome
then
I
then
I
will
then
I
will
let
you
share.
C
C
Right,
I
hope
you
can
see
now.
Is
it?
Is
it
working
yeah?
You
can
see
yes
yeah
so
so
this
is
the
current
state
of
the
document.
C
Basically,
the
the
last
changes
that
we
did
was
that
ludmila
introduced
this
part
for
processing,
and
what
we
did
is
that
we
made
it
clear
that,
if
the
if
the
instrumented
library
supports
offering
processing
a
single
cloud
event,
then
the
the
instrumentation
should
create
the
processing
span
to
trace
it
and
that
you
should
use
the
that
the
instrumentation
should
use
the
trace
context,
that's
in
the
event
and
and
use
it
as
a
link
on
the
processing
span.
C
So
this
is
this
part
here
and
we
decided
to
leave
batching
like
to
to
to
to
to
specify
what
to
do
with
with
batching,
because
we
have
this
issue
of
maybe
a
maybe
instrumentation
library
pass
the
whole
batch
to
the
client
code
and
there's
no
way
to
process
to
create
one
processing
spam
for
each.
So
it's
and
then
there's
also
the
problem
with
attributes
and
so
on.
So
we
just
select
one
for
now.
C
I
think
ludmila
has
more
input
into
this
so,
and
the
other
part
is
that
we
also
added
this
note
here,
highlighting
that
this
there's
not
really
like
a
pattern
or
or
or
standard
how
to
process
cloud
events,
because
some
sdks
offer
like
a
handler
or
off
offer
clients
like
the
go
one
but
others
don't
so.
Users
are
basically
on
their
own
of
of
deserializing
events
and
processing
them.
C
So
we
just
noted
here
that
maybe
a
library
will
have
a
handler
and
then
that
the
the
library
can
can
auto
instrument
the
processing
call,
so
the
user
doesn't
have
to
do
anything.
But
in
other
case
where
there
is
not
a
library
or
the
library
doesn't
offer
such
such
thing,
then
the
instrumentation
is
is
responsibility
of
the
of
the
application
owner.
So
that
was
the
change.
So
so,
if
I
may,
if
I
may
interject
for
a
second.
F
If
you
can
scroll
up
yeah,
because
before
you
get
into
all
the
details,
there
is
a
exactly
instrument:
instrumentation
should
create
a
new
spend
populate,
distributed
trace
extension
on
the
event
just
stopping
there.
For
a
second,
we
had
a
p.
We
had
an
issue
in
cloud
events
open
for
a
while,
which
we
closed
last
week,
which
was
to
remove
the
distributed
tracing
extension
outright,
because
there
was
a
lot
of
contention
about
whether
it
should
exist.
Now
you
guys
like
it,
which
is
great.
F
So
I
would
like
to
encourage
you
to
make
a
pr
on
that
extension
and
basically
claim
it,
meaning
we're
gonna,
keep
it
we're
going
to
have
it,
but
it
should.
F
It
should
really
link
to
this
spec
and
say
if
you
want
to,
if
you
want
to
find
out
how
that's
going
to
be
used
or
point
and
then
point
to
this
place,
because
that's
what
we
people
have
been
confused
on
what
it
is
for-
and
I
think
you
guys
are
the
ones
who
are
providing
reason
behind
it,
and
so
you
should
feel
free
to
go
and
basically
claim
it
and
say
this:
is
the
open
telemetry
distributed
tracing
extension
extension
for
cloud
events?
F
It's
going
to
remain
in
that
place
where
it
is,
you
simply
go
and
point
to
this
spec.
That
should
be.
That
should
be
a
pr
that
then
gets
merged
whenever
this
year
is
done,
but
it's
it
makes
sense
to
kind
of
have
this
already
kind
of
in
on
the
record,
we're
we're
endlessly
patient
in
the
cloud
events
project
we
have
prs
which
have
been
sitting
there
forever.
So
so
it's
okay
to
to
have
it
already.
So
that's
that's.
That's
the
first
comment
and
then
the
second
is.
F
F
So
when
you're
saying
cloud
events
pro
you're
doing
normative
text
here
right,
which
means
you
can
set
the
rules
of
how
you
think
this
this
should
happen,
and
if
people
are
not
doing
are
doing
weird
stuff
right
now
or
they're
doing
this
unguided
or
in
a
way
that
you
find
strange
or
inconsistent,
it
is
up
to
you
to
go
and
fix
it,
meaning
if
someone
is
using
distributed
tracing,
they
should
be
looking
at
the
trade.
They
will
find
the
tracing
extension.
F
They
will
then
go
and
find
this
extension,
and
they
should
then
go
and
find
the
normative
way
of
how
they
should
go
and
do
the
implementation.
So
you
can
actually
cause
the
cloud
events
sdk
to
change
right
to
conform
to
the
way
how
you
do
tracing
and
that
that's
that's
the
right
idea
here
so
don't
feel
don't
feel
constrained
by
the
facts
that
exist
in
the
sdks,
because
ultimately,
tracing
is
a
thing
that
kind
of
happens
under
the
covers
and
doesn't
doesn't
necessarily
face.
F
The
the
the
consumer
so
feel
feel
free
to
be
a
bit
more
constraining
here
on
what
the
on
what
the
code
should
look
like.
C
What
do
you
mean
because
I
mean
if
the
first
point
I
I
I
completely
agree,
so
I
saw
that
issue
as
well
like
some
months
ago,
when
I
was
working
with
the
go
and
then
I
was
also
a
bit
confused,
but
I
I
will.
I
will
open
that
I
will
make
sure
to
open
the
pr
and
point
here.
I
think
I
think
that
makes
sense.
Yes,
so
your.
F
F
And
I
have
I'm
I'm
willing
to
live
with
it.
You
should
not
be
willing
to
live
with
it.
You
should
go
and
say
this
is
how
this
needs
to
change.
Right
needs
to
be
consistent
for
this
to
work.
You
should,
you
should
feel
entitled
here
to
to
to
to
make
to
set
the
rules,
how
the
cloud
events
go.
Sdk
and
the
c-sharp
sdk
and
all
those
sdks
ought
to
do
the
tracing
stuff
right.
C
But
should
this
be,
for
example,
should
this
text
say
like
the
called
events
should
or
expose
a
way
of
handling
events,
and
then,
but
like
I
thought
that
shouldn't
this,
be
something
that
I
should
open
in
the
cloud
events
back
and
then
the
the
sdk
should
comply.
Then,
because
I'm
not
sure
if
it
makes
sense
to
put
here
what
the
sdks
should
do
or
the.
F
Path
is,
and
then
I'm
going
to
be
quiet
and
let
you
guys
continue,
but
the
path
should
so
cloud
events
has
no
notion
of
distributed
tracing
until
you
add
the
cl
the
distributed
tracing
extension
right,
that's
one!
That's
when
that's
when
tracing
actually
plays
a
role
in
cloud
events.
Otherwise
it's
just
you
know
cloud
development
travels
on
transport
that
may
have
tracing,
but
the
condiment
has
nothing
to
do
with
it,
but
once
you
add
the
distributed
tracing
extension
once
you
start
using
it,
then
you're
entering
effect.
F
F
There
should
be
rules
of
you
know.
How
do
you
create
tracing
out
of
this
and
for
which
operations
does
tracing
work
in
the
following
way?
And
and
at
that
point
I'm
saying
I'm
not
an
expert
on
tracing
and
what
how
things
should
work.
But
you
should
feel
entitled
to
go
in
and
and
and
and
tell
the
sdk
owners
how
to
implement
tracing
right,
because
if
they
choose
to
support
the
extension,
then
they
have
to
support
the
extension
correctly.
So
I
I
consider
as
a
cloud
events
person.
F
C
Yeah,
I
see
yeah
because
the
the
the
processing
statement
there,
it
kind
of
kind
of
goes
into
this
direction,
saying
that
if
the
library
supports
processing
cloud
events,
then
instrumentation
should
create
a
new
spin.
So
I
think
that
part
is
is
quite
clear.
I
think
the
note
the
idea
was
just
to
instruct
or
to
as
a
warning
or
something
that
you
might
encounter
sdk
that
doesn't
and
then
what
what
you,
what
to
do
in
that
case,
but
maybe
we
can
write
in
a
different
way.
Yeah
the
sdks
might
change
right.
F
So
the
question
is:
how
do
how
do
you
formulate
this
text
against
again
something
that
might
change
so
the
cloud
events
go,
sdk
may
change
your
mind
and
then
and
then
suddenly
you
have
a
normative
text
which
points
to
it
to
which
is
no
longer
the
truth.
The
question
is:
how
do
you,
how
do
you
make
this
instructive
so
that
it
must
follow
it.
B
D
C
C
For
the
first
one
I
I
can
do
this,
I
will
do
I
will
send
the
pr,
so
they
are
aligned
and
at
least
there
is
a
link
between
them,
yeah
and
because
I
was
also
concerned
that
people
would
close
or
would
remove
it,
because
I
saw
some
people
against
it.
No
don't
remove
it.
Please
I
I
I
put
I
I
kept
my
finger
on
it
yeah
I
saw
that
you
commented
that
it's
important
and
so
on
all
right.
C
Yeah
ludamira
did
you.
I
had
to
want
to
say
something.
A
No,
I
just
want
to
talk
for
a
second
about
the
butchering
part,
if
you
don't
have
anything
yeah,
so
just
to
get
your
opinions
and
maybe
yes
or
nays,
that
with
budgeting
on
consumption
site,
we
they
have
no
current
way
to
express
attributes
properly
right
when
we
create
the
batching
span
and
we
have
the
same
issue
for
messaging.
A
We
have
the
same
issue
for
databases
who
do
some
batching
sometimes,
and
I
think
we
have
an
issue
on
our
created
to
do
well
back
about
databases.
A
B
A
B
B
I
mean
that
is
a
great
point,
because
there
would
anybody
wanted
to
talk
about
like
batching
in
the
wider
sense
of
messaging
later,
but
but
regarding
process
batching.
I
would
actually
be
interested
about
the
like
the
questions,
especially
the
people
here
in
the
meeting
who
have
done
instrumentation-
and
I
wondered-
is
this
a
popular
use
case
that
you
have
to
instrument
process
batching,
meaning
that
you
basically
would
have
one
processband
that
that
handles
multiple
multiple
messages?
B
C
C
Somewhere
further
yeah,
it
highly
depends
on
the
use
case.
I
guess
I
don't
know
man
seems
like
it
yeah
yeah,
so
I
can
also
quickly
show
the
demo
that
I
prepared
from
from
last
week.
So
I
have
so
now
it's
it's
following
this
semantic
commission
the
way
it
is
written
at
this
point
now
so
using
links
and
so
on.
So
I
have
a
simple
client,
receiver,
sender
and
receiver
via
htp.
C
Here
I
guess,
can
you
see
it
well?
Is
it
big
enough
or
should
I
zoom
in
or
does
it
mean
a
little
bit
more?
I
can
see
that
yeah.
So
there
is
the
like
this
yeah.
So
there
is
the
the
client
here
and
then
the
server,
so
the
client
normally
creates
the
event,
and
then
we
follow
the
conventions
here,
the
name
and
so
on,
and
because
both
both
applications
are
also
instrumented.
So
we
have
the
transport
spans
here.
The
post
here
and
the
server
is
also
autistic.
C
So
we
have
the
middleware
http
receiver
here,
but
then
we
have
the
processing.
So
here
is,
is
the
processing
and
we
can
see
it
has
a
link
then
to
the
to
to
decorate
here.
The
other
link
is
because
the
child
is
always
linked
to
hearing
neger.
It
seems,
but
the
one
is
here
so
that
one
is
the
instrumented
library
doing
it
and
the
links
to
the
creative,
but
because
they're
all
auto
instrumented.
C
So
it
looks
like
a
parent-child
relationship
really
because
it's
just
like
a
let's
say
a
synchronous
call
more
or
less
so
this
looks
quite
straightforward
and
then
the
server
after
receiving
it
I
just
created
another
call
just
to
exemplify
that
it
could
send
another
event
and
you
would
have
it
would
have
it
here
as
well
as
a
child
yeah,
and
the
other
example
that
I
have
is.
C
Get
to
it
and
there's
this
zoom
to
second,
yes,
yeah.
So
the
other
example
is
this,
which
was
an
application
that
I
was
instrumenting
some
time
ago,
which
consists
of
a
producer,
and
then
it
sends
sends
the
cloud
of
nvhtp
to
intermediary,
and
then
this
intermediary
puts
it
on
a
queue
and
then
there's
the
consumer
is
is
subscribed
to
the
queue
and
then
he
gets
the
message.
The
event-
and
this
way
this
looks
like
right
now
is
that
so
here
is
the
because
niagara
cannot
see
that,
but
they
are
separate.
C
But
here
we
have
the
producer
so
the
create
event,
and
then
all
the
instrumentation
kicks
in
again
and
then
we
have
the
post
and
the
intermediary
here
also
has
the
http
auto
instrumented.
So
we
have
this.
We
have
this
span
here.
This
is
just
from
the
auto
instrumented
library,
nothing,
not
nothing
that
I
actually
did
so
here
we
have
until
it
reached
to
the
intermediary.
And
then,
if
you
look
at
the
consumer,
then
the
consumer
receives
it
from
the
queue
and
there
is
a
processing
here.
C
And
if
we
look
here,
the
processing
span
has
a
link
here.
I
will
not
click,
because
my
jager
is
not
running
so
I'll
get
a
40404,
but
but
the
link
is
here
and
then,
if
I
click
it
will
open
this
one
here.
So
that's
that's
how
it
will
that
how
it
looks
like
today
and
then
here
again.
I
also
did
another
request
just
to
exemplify
sending
more
more
more
events
after
receiving
one.
C
Yeah,
so
this
is
what
we've
been
discussing
for
from
some
from
some
time
now
that
in
the
current
spec
in
the
messaging
spec,
there
is
some
examples,
and
some
of
them
are
laid
out
using
parent-child
relationships
and
some
of
them
where
there
is
more
complicating,
complicated
flows
than
link
link
is
used
and
we
are
kind
of
trying
to
make
them
consistent.
And
then
that's.
C
Why
that's
why
we
chose
to
use
links
and
that's
why
we
we
are
trying
to,
at
least
in
the
cloud
event
to
stack
out
that
when
processing
the
the
that
you
should
add
a
link
of
the
create
span
into
the
processing
span.
A
I
would
like
to
add
that,
basically,
we
have
two
things
right:
there
we
have
a
parent,
potentially
whatever
context
the
consumption
happens
in
and
also
we
have
a
context
in
the
cloud
event
itself.
So
if
we
choose
to
create
a
parent
out
of
the
cloud
event
context,
then
we
probably
have
to
link
the
ambient
context
right.
So
we
don't
lose
anything
and
it
sounds
way
more
consistent
and
easier
for
any
instrumentation
to
just
automatically
get
the
ambient
context
as
a
parent
and
then
the
the
cloud
event
becomes
a
link
and
yeah.
A
E
F
E
Started
and
where
it
ended
as
one
trace
to
me
that
feels
more
natural.
C
Yeah
and
what
we'll
be
discussing
as
well
is
that
I
mean
last
week,
ludmila
showed
the
demo
in
azure
monitor
and
there
you
can
see
in
in
one.
Let's
say
in
one
page:
you
see
them
somehow
linked
below,
like
it
was
a
parent
child,
more
or
less
relationship,
but
we
discussed
as
well
that
because
the
visualization
or
the
tools
or
the
vendors
are
not
yet
fully
equipped
to
deal
with
links
that
we
should
not
use
it
in
this
space.
G
G
Just
level
set
just
for
a
second
and
I
apologize
because
I
came
like
this
discussion,
but
is
this
linking
only
in
the
context
of
when
we're
doing
pub
sub
with
cloud
events,
or
is
this
more
general
pub
sub
that
the
the
pro
the
the
there's
a
potential
to
use
links
like
if
we're
not
using
cloud
events
or
just
you
know,
doing
generic
events?
Would
there
be
linkages
in
that
case,.
B
That's
that's
what
we
are
gonna
figure
out
in
this
group:
okay,
but
the
currently
like
also
regarding
the
discussions
we
had
or
in
during
the
last
weeks.
We
there
are
definitely
scenarios
that
we
can
only
model
with
links,
so
we
cannot
cover
all
scenarios
with
parent-child
relationship,
for
example,
when
you
have
batching
or
even
zhao.
B
If
you
want
to
want
to
show
this,
the
synchronous,
http
scenario
that
you
showed
in
the
beginning,
this
you
can
also
not
cover
with
parent
file
relationships,
because
here
you
see
the
cloud
events
create
in
the
cloud
events
process.
B
B
We
will
have
to
challenge
between
user
friendliness
and
deficiency,
because
parent-child
relationships
are
kind
of
more
efficient
and
on
the
other
hand,
there
is
like
the
challenge
of
consistency,
to
have
like
a
consistency
to
a
consist,
a
consistent
model
across
all
the
scenarios
that
you
want
to
support
and
something
the
trial.
Also,
like
said
before
that,
currently,
when
we
show
links
here
in
jaeger,
that
might
be
that
might
look
weird,
and
it
also
is
a
bit
weird
and
cumbersome
to
navigate
those.
B
But
we
we
expect
the
support
for
links
in
vendor
back-ends
to
improve,
and
there
are
some
examples,
for
example,
azure
monitor
that
already
inline
the
links.
So
if
you
have
a
link
trace,
you
see
it
kind
of
inlined
in
the
same
view
as
as
the
basically
both
traces
in
the
same
gantt
chart,
and
you
see
the
how
they
are
linked
together
and
we
expect
other
other
visualizations
and
banter
backhands
to
catch
up
with
that.
E
My
my
sense
is
that
if
there
is
only
one
sort
of
if
you
really
only
want
one
link,
that
a
parent-child
relationship
is
a
good
way
to
express
that
and
and
links
come
in
handy
when
there
is
no
single
other
thing
to
link
to,
and
you
need
to
point
to
many
things
like
and
if
you
can
like,
if
you
have
a
parent-child
relationship
for
a
sequence
of
events
that
occurs,
I
think
that
makes
a
lot
of
sense.
E
I
I
understand
where,
when
you
have,
you
know,
if
you
have
a
batch
and
and
everything
in
a
batch
needs
to
reference
each
other
or
something
like
that,
like,
obviously
you
have
no
choice
but
to
use
links
at
the
same.
A
Time
you
still
have
the
ambient
context
right
and
this
this
processing,
it
happens
in
some
context,
and
if
you
overwrite,
the
parent
you
would
have
to,
you
would
either
lose
this
context
or
you
would
have
to
express
it
as
a
link
right.
You
cannot
say
it
happens
in
out
of
nowhere
at
least
not
not
all
the
time.
E
I
guess
I
I
I
don't
understand
all
of
the
ian's
notes
of
cloud
events.
I
I'm
speaking
a
little
bit
more
generically
in
messaging.
Maybe
we
should
wait
if
we're
focused
on
the
cloud
event.
Specification
here
defer
this
discussion
until
later.
A
E
Yeah,
I
think,
keeping
the
parent
child
racist
in
the
sequence
of
things
happen.
If
you
go
from
like
a
cloud
events
down
to
a
transport,
you
know
onto
an
intermediary
onto
your
queue
through
a
transport
like
to
me
that
sequence,
anything
that
happens
is
expressed
as
parent
child.
If
you
want
to
link
to
the
cloud
of
like
you,
have
a
cloud
events
process
and
the
cloud
events
create
with
transport
stuff
in
between,
but
you
want
to
link
those
that
makes
sense
to
link
to
to
model
that
with
a
link.
I
think.
F
But
if
you,
if
you
shave
the
cloud
event
away-
and
you
say,
let's,
let's
discuss
amkp-
I
think
the
basic
interactions
and
the
way
how
the
contacts
play
a
role
relative
to
operations
and
retrieval,
etc,
largely
remain
the
same,
which
means
there
is
some
extension
that
needs
to
be
put
into
the
into
the
mqp
message,
and
we
can
argue
whether
that's
a
message
annotation
or
whether
that
needs
to
be
your
property
and
then
and
then
that
flows
and
on
the
other
side,
there's
a
receiver
which
goes
in
and
starts
without
has
its
own
context
to
receive,
because
there's
the
receiver
operation
is
something
that
needs
to
be
traced.
F
It
picks
up
a
message,
and
now
in
that
message
comes
it
becomes
another
context.
So
I
think
that
the
way
how
those
things
interact
are
the
same,
irrespective
of
what
the
the
the
abstraction
that
is
that
sits
on
top.
Sometimes
you
have
effectively
mkp
or
mqtt
or
kafka
naked.
If
I
may
say
so,
and
sometimes
you
have
the
the
the
cloud
event,
abstraction
layered
on
top.
E
Yeah
yeah
and
I
think
that,
like
like
sequentially
showing
the
layers,
all
the
layers
interact
with
each
other
as
parent-child
relationships
make
sense
to
me.
F
The
the
extra
the
extra
the
extra
issues
that
are
coming
into
play
are:
how
do
we
deal
with
pull
because
there's
an
operation
that
starts
before
you
even
know?
What
the
context
is
that
comes
across
the
wire
from
the
other
side
and
how
to
deal
with
battery.
C
And
I
think
also
one
one
thing
that
I
thought
before
is
that,
if
you,
for
example,
if
if
you
receive
a
message
and
there's
already
a
context,
somehow
there's
already
a
context
happening
and
then,
if
we
want
to
to
to
have
like
parent
child,
then
the
user
like
specifically,
have
has
to
like
drop
in
or
ignore
the
current,
the
current
context
and
then
choose
like
I
choose
the
to
to
use
the
one
that's
coming
in
the
message,
and
I
think
the
other
way
around
is
more
fluent
because
I
don't
have
to
deal
with.
C
I
don't
like.
I
don't
even
have
to
see
if
there
is
already
a
current
context.
I
just
know
that
I
might
have
one
in
the
event
and
if
I
do
I
add
a
link,
but
I
don't
have
to
mess
with
the
current
context
and
and
that
that
would
entail
that
I
would.
I
have
to
do
things
in
my
code
like
as
a
as
a
as
an
application
owner
do
like.
Do.
I
have
a
current
current
context.
I
do
I
I
do
then
then
do
this
and
otherwise
do
that.
So
I
think
it's
yeah.
F
F
F
Now
you
get
a
message
and
on
the
next
line,
you're
calling
a
callback
and
calling
into
a
processor
which
which
is
hooked
to
this
to
this
loop.
Now
you
have
a
message
that
message
comes
in
and
already
and
now
has
a
context.
Now
you
have
two
contacts.
You
have
the
one
of
the
receive
operation
which
is
being
called
from
and
which
is
now
calling
this
this
handler.
F
F
What
is
that
right
context
to
to
handle
so
so
that
I
think
that's
the
like?
We
can.
We
have
some
fairly
simple,
simple
constructs
like
like
imaginary
pseudo
code,
that
we
can
go
and
construct,
but
we
fairly
easily
see
the
role
changes
between
there's
an
outer
receive
loop
that
always
exists
on
pull
on,
pull
as
polar
surfaces
and
then
there's
a
context
switch
where
the
the
context
of
the
message
matters
but,
as
you
are
crashing
out
of
the
handling,
then
you're
effectively
swapping
back
into
that
context.
F
Arguably,
in
the
thing
that
crashed
in
the
handler
that
you
call
that
doesn't
care
about
how
the
message
has
been
received,
if
you
crash
back
into
into
the
perceived
loop
and
that
might
cause
some
trouble,
then
then
that
context
matters
again.
So
that's
that's!
That's
something
to
think
about
how
we're
going
to
go
and
deal
with
that,
so
those
so
that
pseudo
code,
I
think,
will
what
I
just
you
know
painted
that
might
be
helpful
helpful
to
to
figure
out
what
the
right,
where
the
boundaries
are.
C
B
Definitely-
and
I
would
like
to
add
something
to
what
the
cameron
said
here,
because
we
were
talking
or
joanne
was
mentioning-
that
there
are
things
that
are
sequential
should
be
parented,
and
I
agree,
but
I
think
another
challenge
that
we
also
have
here
is
that
you
can
have
different
views
on
what's
happening
and
with
those
different
views,
the
sequence
can
change.
The
sequence
of
events
can
change.
I
mean
draw
if
you
want
to
show
this.
B
That
is
one
view
from
the
message
point
of
view
to
see
kind
of
the
sequence
method
is
created
in
the
producer,
it's
processed
in
a
consumer,
but
then
there
is
this
other
view
where
you
also
take
the
intermediary
into
account
that
happens
in
between
and
there,
then
you
have
a
slightly
different
sequence,
because
then
you
have
producer
might
be
then
parented
to
intermediate
events
and
intermediate
events
might
be
parented
to
consumer
events
and
by
by
using
links
to
basically
to
link
those
message.
Events
together,
we
this
view
is
much
more
flexible
and
it
supports.
B
That
was
another
reason
why
we
kind
of
tended
to
go
with
with
links
instead
of
spence,
and
I
think
it's
it's
by
by
the
way.
It's
definitely
fine
to
have
this
discussion
at
this
point
because
yeah
we
are
discussing
this
in
the
context
of
cloud
events
now,
but
I
think
the
cloud
events,
it's
kind
of
a
first
step
at
how
we
are
going
to
do
this
in
messaging
in
general.
B
So
please
feel
free
to
like
continue
the
discussion
here.
If
you
have
any
doubts
about
what
we
come
up
with
for
cloud
events.
E
Yeah
and
I
mean
in
terms
of
the
intermediary
participation,
like
sort
of
I
I
would
view
you
have
an
intermediary
who
may
participate
in
tracing
or
may
not,
and
you
know
if
we
think
that
the
sequential
events
you
know
parent-child
relationship
makes
sense.
Then
you
know
if
the
intermediary
participates.
He
creates
spans
where
the
producer
is
the
parent
and
modifies
the
you
know
the
span
context
being
propagated
down
to
the
consumer,
such
that
when
the
consumer
parents,
to
the
span
context
that
his
that
the
process
event
is
apparent
of
the
intermediaries.
E
You
know
I
don't
deliver
or
in
queue
type
of
event,
and
and
that
way
you
get
a
chain
all
the
way
through
and-
and
I
guess
so-
that's
the
view
I
build
in
my
head
and
I'm
trying
to
understand
what
the
the
alternate
that
the
alternate
way
of
looking
at
is.
Is
it
maybe
that
the
consumer
has
a
parent
of
the
producers
and
the
intermediary
creates
spans
that
are
have
links
to
those
or
I'm
just
trying
to
understand
the
different
proposals.
A
C
Yeah-
and
one
thing
that
I
can
say
as
well
is
that
I
was
instrumenting
this
large
large
project
that,
like
hugely
uses
cloud
events,
and
my
idea
was
that
I
I
would
be
nice
also
have
like
a
parent
child
because
it
would
make
it
make
it
easier
to
to
see
what's
happening.
So,
for
example,
in
the
one
case
that
I
was
instrumenting
like
a
single
produced
event
would
trigger
producing,
I
think,
six
or
seven
more
events.
C
It
would
hook
into
github
notifications
and
produce,
like
a
lot
of
other
things
and
like
I
managed
to
make
it
like
fully
complete
a
trace,
fully
complete
with
parent
child.
But
that
entails
that
I
between
the
hops,
I
would
have
to
grab
the
current
context
and
then
change
the
the
context
that
I
put
inside
events.
So
when
the
event
goes
to
another
thing,
it
can
continue
the
trace.
C
C
B
One
option
is
just
to
have
your
the
direct
link
between
pros
producer
and
consumers
bands
and
then
have
the
link
link
like
intermediary
operations
to
those
traces
or
the
other
way
would
be
to
kind
of
have
the
parent
tribe
relationship
throughout
producer
intermediary
consumer
and
then
link
the
creatine
process
bands
together,
because
here
we
have
basically
those
two
different
layers
of
context
that
we
need
to
connect.
Somehow
and
basically
one
layer.
B
We
can
connect
by
apparent
child
relationship,
but
the
the
this
parent
type
relationship
only
works
for
one
layer,
because
it's
kind
of
a
one-dimensional
way
of
connecting
things.
So
for
the
second
layer
we
need
like
this.
We
need
links
to
connect
them,
and
I
think
it's
just
a
question
here
here
which
layer
uses
what
mechanism
yeah
and.
E
B
E
I
like
clemens
example
there
with
kind
of
is
it
the
applications,
call
to
receive
that's
the
start
of
the
trace,
or
is
it
kind
of
the
end-to-end
journey
of
the
message
that
the
application
receives?
That's
that's
the
the
trace
and
that's
that
to
me
is
like
a
very
interesting
easy
to
understand.
D
Would
it
be
helpful
for
us
to
also
be
trying
to
look
at
this
for
specific
systems,
just
like
kafka
or
amtp,
and
sorting
out
the
needs
for
those
specific
systems
like
I
just
I
guess
what
I'm
wondering
is
by
just
dealing
at
the
meta
level.
Are
we
are?
Are
we
confusing
ourselves
a
little
bit.
F
What
I
think
is
that
being
concrete
is
good,
and
so
solving
this
for
cloud
and
solving
this
for
cloud
events
is
not
a
terrible
start,
because
we
we
will
have
to
solve
the
mqtt
and
mqp
exist
for
a
reason
each
does,
and
so
does
kafka
and
pulzar
and
provega
and
all
those
other
proprietary
or
project
proprietary
protocols,
and
so
I
think
it
is.
It
is
right
to
go
and
start
with
one
and
then
and
then
there
will
be
parallels
and
there
will
be
some
some
things
different.
F
D
Yeah
yeah,
I
guess,
like
my
my
only
concern
I'd
like
to
raise,
is
that
if
we
get
just
from
a
time
perspective
right
like
if
we
get
like
super
far
down
a
model
using
just
one
of
these
systems
and
then
later
come
back
with
another
system,
we
want
to
model
and
then
discover,
there's,
there's
stuff
that
has
to
be
worked
out
between
those
systems.
Would
it
be
slower
to
do
them
one
after
the
other?
Or
would
it
be
the
question.
F
Here
is
the
question
here
is
whether
we
even
want
a
whether
we
want
to
do
whether
we
want
to
do
an
abstraction
here
and,
and
I'm
not
sure,
that's
healthy,
because
cloud
events
per
se
is
already
an
abstraction
right
and
that
has
that
binds
to
down
to
various
transports.
F
So
we'll
do
a
solution
for
cloud
events
and
then
we
will
get
but
not
everybody's
using
cloud
events,
but
it's
using
other
standards
and
obviously
what
we
want
to
do
here
is
we
want
to
go
and
and
and
do
a
standard
and
drive
standards
right.
What
we
don't
want
to
do
is
one:
do
we
don't
want
to
go
and
and
and
use
the
standard
to
promote
proprietary
technology?
F
So
therefore
you
would
then
go
and
say:
okay,
so
so
now
we
need
to
have
a
standard
solution
for
also
for
amqp.
What
we'll
find
is
likely
that
patterns
we've,
we've
explored
here
and
and
found
out.
We
can
also
go
and
apply
to
mqp,
but
it
should
be
concrete
that
the
my
my
my
fear
is
with
all
of
the
all
of
the
extra
standards
is
that
they
try
to
find
yet
another
abstraction.
F
F
Right
kafka
has
partitions,
it
has
a
notion
of
consumer
groups,
it's
a
different
animal
than
than
than
what
cloud
events
does
and
okay.
D
So
yeah,
that's
that's
great
yeah!
I
I
think
I'm
coming
from
when
you
know
when
we
were
modeling,
maybe
more
fundamental
things
in
tracing
we
needed
to
to
look
at
java
and
go
and
python
to
make
sure
we
were
building
something
that
could
be
implemented
across
all
of
them,
but
you're
right
in
this
case,
that's
not
necessary,
we're
at
a
little
bit
higher
level
and
it's
okay
to
to.
If
these
models
don't
don't
fully
overlap
with
each
other.
F
What's
interesting
and
and
that's
an
interesting
thing
to
kind
of
step
back
from
and
observe
for
a
moment
is
everybody
is
totally
happy
to
go
into
htp
in
in
in
same
detail
right
and
do
binding
and
work
and
worry
about
bindings
for
http
down
to
every
return
code.
With
with
some
interpretations
of
what
the
return
codes
are
and
and
the
messaging
protocols
desire
the
same
level
of
attention.
D
A
Yeah
and
also
to
add
to
this,
if
we
remember
the
johannes
beautiful
picture
of
four
stages,
the
create
send
for
create,
publish,
receive
process,
we're
talking
about
create
and
process
when
we're
talking
about
cloud
events,
and
it
should
be
applicable
to
anything
that
happens
on
the
transport
level.
So
we
are
taking
a
half
of
the
problem
and
so
solving
a
small
scope
problem
that
will
help
us
solve
the
next
one.
B
Yeah
I
I
also
agree.
I
mean
that
was
a
reason
why
I
pulled
like
all
these
cloud
events
discussions
in
here,
because
yeah,
I
think,
there's
definitely
considered
overlap
with
messaging
and
also
agree
with
comments
that
I
think
it
makes
sense
that
we
maybe
try
to
find
the
solution
for
the
claudio
and
stuff,
and
then
we
move
on,
because
I
actually
think
it
would
be
counterproductive
to
do
now.
B
Context
switch
okay
and
switch
to
kafka,
but
I
definitely
think
that
is
the
next
step
that
we
then
take
once
we
have
the
cloud
event
stuff
figured
out,
and
I
also
think
this
context
propagation
questions
that
takes
us
quite
some
time,
but
I
think
that
is
the
biggest
and
most
complicated
question
to
answer
like.
Do
you
think,
once
we
are
over
this
kind
of
over
this,
like
once,
we
are
past
this
question.
B
D
Yeah,
sorry,
I
I
have
one
other
point.
I
want
to
make
that's
relevant
and
then
I'll
I'll
seed,
there's
another
working
group
that,
unfortunately,
because
of
like
a
time
conflict
I
have
not
been
able
to
go
to,
which
is
the
client,
instrumentation
group
and
they're
focused
on
from
real
user
monitoring.
D
But
I
know
their
their
core
issue
was
that
clients
have
this
reactor
style
pattern
and
user
monitoring
doesn't
easily
fit
into
a
transactional
tracing
model
and
they
were
feeling
like
they
needed
something,
a
little
more
event-based
and
something.
I
wonder,
looking
at
some
of
the
stuff
we're
doing
here
around
message,
processing,
especially
around,
for
example,
like
the
message
creation
component.
D
Sometimes
some
of
it
feels
a
little
bit
like.
I
wonder
if,
like
we
should
keep
a
little
bit
track
of
what
they're
thinking
about
in
that
group,
because
sometimes
it
feels
to
me
like.
Maybe
these
things
are
not
like
full
spans
or
something
like
this.
This
is
like
event,
context
that
we're
trying
to
juggle
anyways.