►
From YouTube: 2021-10-28 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
Let's
give
it
a
maybe
two
more
minutes
and
then
get
started
if
you
have
anything
for
the
gender
feel
free
to
edit.
For
today,
I
added
just
one
short
note
about
like
a
hotel
road
map
that
is
being
put
together,
and
then
I
added
the
cloud
events
discussion
that
we
didn't
get
to
last
week
and
when
there's
time
left,
we
can
continue
the
context
publication
discussions.
If
you
have
any
additional
points,
just
feel
free
to
put
them
on
the
channel.
C
D
D
Yeah.
Thank
you.
Thank
you
all.
I'm
I'm
happy
with
the
the
slate
of
people
who
got
elected,
I'm
happy
to
be
reelected,
but
I'm
also
happy
that
jp
got
on
the
governance
committee.
F
A
Okay,
third,
four
past
eight,
let's
get
started.
I
put
this
first
point.
I
will
share
my
screen.
That
might
be
easier.
First
point
on
the
gender,
which
is
about
like
an
hotel
road
map,
state
of
open
dynamite.
Q4,
maybe
also
ted,
can
say
something
to
that,
but
I
put
it
on
there
because
they,
the
people
who
put
it
together,
were
asking
for,
like
estimates
or
kind
of
estimates,
for
deliverables
for
the
semantic
convention
work
and
on
tuesday,
a
group
what
it
was
discussing
about
this
mostly
focused
on
http
and
there.
A
The
consensus
was
that
there
we
are
trying
that
that
will
be
trying
to
ship
a
stable
1.0
version
at
the
end
of
q1
2022.
So
that
would
be
a
march
2022
and
yeah.
We
just
put
the
same
in
here
for
messaging,
also
that
we
said
yeah
4d
for
cuban
2022.
We
want
to
have
a
stable
version
1.0
also
for
the
messaging
semantic
conventions,
just
kind
of
to
make
people
aware
that
we.
A
Made
this
kind
of
a
commitment.
I
think
it's
not
a
hard
commitment,
but
it's
just
to
give
the
community
some
kind
of
orientation
where
the
project
stands
and
what
they
can
expect.
A
D
So
we
we
discussed
this
on
tuesday
for
the
http
semantics
and
we
agreed
and
if
q1
is
a
reasonable
goal.
End
of
this
year
seemed
sketchy
just
because
you
know
november
december,
often
like
pretty
low
productivity
months.
D
It
seems
to
me
that
metrics
or
sorry,
metrics
messaging
yeah,
likewise
would
be,
would
be
reasonable
to
I
mean
I
hope
we
have
this
done
by
end
of
q1.
I
honestly
feel
like
if
it's
not
done,
if
either
of
these
things
are
not
done
by
end
of
q1,
it's
because
we've
stalled,
or
we
haven't
developed
enough
interim
milestones
to
to
get
things
like
over
the
finish
line.
But
that's
that
seems
like
more
than
enough
time
to
to
get
this
to
a
point
where
we
should
be.
D
I
think
the
we
discussed
this
on
the
http
side,
but
to
call
these
things
stable.
We
have
to
have
a
proposed
plan
and
then
we
also
need
to
have
some
prototypes
right.
We
need
to
take
some
instrumentation
in
a
couple
languages
and
actually
implement,
but
these
new
conventions
and
just
confirm
that
it
actually
like
looks
good
and
it's
it's
feasible
to
to
implement
this
stuff.
D
So
maybe,
if
we're,
if
we're
stalled
out,
it
might
be
because
we
haven't
implemented
those
prototypes
and,
as
a
result,
we're
kind
of
going
in
circles
on
the
on
the
spec.
A
A
That
can
happen,
I
mean
for
messaging.
Basically,
I
think
the
roadmap
we
have
at
least
tried
to
lay
out
here
in
the
dock
that
we
got
merged
and
we
have
the
prototypes
here.
That
is
basically
the
last
step
before
actually
merging
any
changes
and
calling
them
stable,
and
we
are
basically
currently
doing
a
preparation
work
for
this
step
where
we
want
to
have
here.
Some
conventions
basically
worked
out
in
an
old
tap.
A
Basically
what
we
do
now
for
context
propagation
that
will
then
the
discussions
will
end
up
the
results
of
those
discussions
will
end
up
in
this
old
tip
and
then
yeah.
There's
also
this
step
three
of
regarding
general
instrumentation,
for
guidance
for
german
instrumentation
problems,
for
example,
or
retries
or
instrumentation
layers.
A
We
kind
of
plan
to
how
to
say
leech
of
some
of
the
work
that
is
going
on
in
the
http
group
because
they
are
dennis.
There
is
working
on
some
channel
guidance
for
retries
and
we
actually
plan
to
use
that
here.
So
there's
also
already
going
somewhere
going
on
here
and
then
there
is
this
step
here
for,
like
stability,
guarantees
in
the
spec
need
to
be
formulated.
That
is
currently
this
here
is
currently
a
to
do
section
in
the
spec,
but
I
actually
think
we
made
also
progress.
A
There
are
other
people
make
progress,
because
I
saw
that
degram
merged
some,
this
schema
format
and
or
the
schema
transformation
stuff
into
the
spec,
and
I
think
we
can
fill
up
this
section
by
just
having
some
description
that
links
to
those
schema
transformations,
because
basically,
everything
that
can
be
covered
by
those
schema
transformations
will
not
require
a
major
version
bump.
D
Yeah
yeah,
we
I'll
say
one
thing
dennis
is
doing
really
good
work
and
one
of
the
things
I
think
that
has
been
helpful
is
having
an
actual
implementation
so
that
we're
looking
at
traces
and
things
in
the
meeting
when
we're
discussing
this
stuff.
So
I
might,
I
guess
that
would
be
the
only
thing
I
would
add
to
to
your
your
road
map.
Johannes,
is
rather
than
waiting
to
the
end
to
to
do
some
prototyping,
having
at
least
like
one
working
example
sitting
somewhere,
so
that
we
can
be.
D
You
know,
kind
of
looking
at
some
traces
in
this
meeting
when
we're
discussing
this
stuff.
I
think
that
could
be
helpful
to
people.
A
Definitely
I
mean
the
only
thing
we
had
in
that
direction
was
like
what
luke
miller
showed
us,
but
I
think
we
definitely
need
some
some
also
some
just
example.
Programs
like
yeah
then
stick
for
hdb
that
just
that
we
can
evaluate
the
outcome
of
different
approaches.
Yes,.
A
A
Okay,
that's
all
what
I
have
for
the
roadmap
and
then
for
the
next
point:
semantic
convention
for
cloud
events
or
first
any
questions
to
the
roadmap
or
any
concerns
from
anybody.
A
If
not,
then
I
hand
over
to
maybe
rau
and
luke
midla
for
the
70
conventions
for
cloud
events.
The
pull
request
that
wanted
to
to
discuss.
E
Yeah
so
yeah
there's
this
intention
that
we're
working
on
on
on
trying
to
bring
some
conventions
for
cloud
events
and
then
yeah.
So
initially
I
don't
know
if
I'll
remember,
but
initially
I
wanted
to
bring
this.
It
was
mostly
the
attributes
that
I
saw
that
they
were
present
already
in
the
cloud.
Events
go
sdk
and
I
thought
it
would
make
sense
to
have
these
attributes
also
in
in
in
the
open,
telemetry
spec.
E
But
then
the
conversation
grew
more
and
and
in
the
sense
that
the
attributes
alone
are
were
kind
of
useless
because
yeah,
the
instrumentation
authors
couldn't
take
this
or
or
there
was
no
guidance
on
how
and
when
spends,
should
be
created,
and
things
like
that,
which
I
agree,
yeah
and
then
yeah.
Then
I
did
some
work
and
then
now
salute.
Mila
also
did
some
work,
and
the
version
that
we
have
now
is
is
like
the
combination
of
the
two
where
we
have
some.
E
There
is
some
more
guidance
when
to
create
it
kind
of
it
more
or
less
follows
what
we
have
been
discussing
as
well
for
messaging.
So
like
we,
the
intention
intention
is
to
create
a
span
when
you
create
a
cloud
event
and
then
put
this
the
span,
the
span
context
inside
the
event
and
then
on
the
producer
side.
When
you
receive
it,
then
the
producer
takes
this
context
from
the
event
and
then
continues
the
trace
and
cloud
events
already
has
this
in
their
spec.
E
They
call
it
distributed
tracing
extension,
it's
it's
a
property
on
the
event
specifically
for
trace
for
to
hold
the
trace
parent
and
the
train,
state
values,
yeah
and
then
the
the
current
state
is
this
yeah
that
we
suggest
that
you
create
a
span
when
you
create
the
event,
and
then
this
part
got
a
little
bit
when
when
ludmilla
opened
the
tent,
we
had
some
discussions
because
there's
part
like
when
should
because
we,
when
you
create
a
cloud
event,
then
you
have
to
create
a
span
as
well,
and
then
you
have
to
put
this
string
context
inside
the
event,
and
then
we
wanted
to
the
discussion
was
that
we
wanted,
to,
let's
say
hide
this
from
the
user,
that
the
user
shouldn't
be,
should
shouldn't
be
responsible
for
fiddling
with
injecting
the
context
and
into
the
event,
and
things
like
that,
so
we
talked
a
little
bit
and
not.
E
But
I'm
not
sure
if
that
will
be
like
a
good
thing
yeah,
so
we
rewarded
so
ludmila
reward
a
little
bit
and
that's
what
you
see
see
there.
It
says
that
the
call
event
is
created
by
the
instrument,
instrumented
library.
It
may
be
impossible
or
impractical
to
create
a
span
during
the
event
creation,
because
it's
just
a
constructor
class
or
there's
a
factory
method
and
so
on.
E
So
the
instrumentation
library
may
create
may
create
a
span
later
when,
when
the
event
is
about
to
be
passed
or
passed
to
the
transportation
layer
and
that's
what
I
yeah
basically
did
in
this
in
the
call
event
go
sdk,
that's
more
or
less
how
it
works
today.
E
So
before
passing
to
the
trans
transport
layer,
the
span
is
created
automatic,
so
the
user
doesn't
have
to
do
anything
and
on
the
processing
side
is,
is
it's
more
or
less
the
same?
So
we
try
to
phrase
in
a
way
that
that
yeah,
the
the
the
the
context
from
the
event
is,
should
be
extracted
and
then
use
it
to
to
create
another
span
for
processing.
And
then
you
will
have
the
proper,
more
or
less
parent
child
relationship
on
it.
So
I
think
that's
that's
pretty
much
it.
E
The
latest
updates
on
this,
and
I
think
the
question
that
lies
now
is-
and
it
was
what
was
discussed
in
the
last
meeting
from
from
last
me
from
last
week.
Is
that
how
we
should
do
this
correlation
yeah?
E
Because
should
we
use
links
or
not
because
johannes,
if
you
want
to
show
your
question,
that
you
open
that
I
think
this
week
or
last
week,
because
I
also
had
the
same
question
that,
for
example,
in
the
processing
side,
it
might
be
that
there
is
already
an
active
span
because,
for
example,
in
a
http
producer,
consumer
simple
scenario,
the
consumer,
if
all
of
them
is,
are
already
instrumented
with
http
libraries
of
instrumented
libraries.
E
Then,
when
the
event
arrives
at
the
producer
there
is
already
a
there
is
already
an
active
span
and
then
what
what
we
should
do
in
that
case,
that
should
the
active
span,
be
the
parent
of
the
processing
operation
or
should
the
context
from
the
event
be
the
the
one
used
yeah.
E
And
I
I
tried
to
create
a
simple
app
to
illustrate
this,
to
see
how
the
trace
would
look
like
following
like
strictly
how
it
was
written
in
the
in
the
proposal
there
and
that's
how
it
how
it
would
look
like
it's
just
a
client
in
server
http
scenario
yeah.
So
you
can
see
that
the
first
one
is
the
create.
So
when
I
create
the
event,
there
is
a
create
span.
E
And
then
you
see
the
post
and
then
the
the
the
two
next
one
is
the
from
the
from
the
instrument
from
the
auto
instrument:
instrumentation,
http
libraries
and
then
below.
You
have
the
receiver
so
the
cloud
events
process
and
then
as
like
to
illustrate
that
there's
more
things
I
just
made
a
a
an
extra
http
call
to
illustrate
that
there's
more
things
below
when
I
process
the
event.
E
But
you
can
see
because
the
the
the
processing
part
I
took
the
trace
context
from
the
event
and
used
that
as
the
parent
span
for
the
processing
span
and
then
that's
why
you
see
that
it's
directly
below
the
create
and
not
below
the
http
receiver
from
the
auto
instrumented
library.
E
And
that's
the
the
quest
that
johannes
I
had
because
the
expanded
you
see,
they're
called
advanced
http
receiver
is
the
current
active
span
on
the
receiver
side
and
I'm
not
sure
I
I
I
think
that
yeah
it
could
confuse
users
in
this
way
because
they
would
say
yeah.
But
I
said
why
is
this
not
aligned
after
it
or
not,
but
yeah?
E
So
I
think
that's
the
point
where
we
we
are
at
now
that
the
this
like,
if
we
should
use
links
in
this
case
or
or
or
we
should
in
this
specific
case,
that
is
like
kind
of
a
sync
scenario,
not
like
a
messaging
asynchronous
and
then
maybe
in
this
case
we
should
take
the
active
span
instead
yeah.
So
I
think
that's
the
point
or
which
is
just
like.
E
This
is
fine
as
well
yeah
and
we
take
the
we
do
it
like,
as
the
proposal
says,
that
should
always
use
the
span
context
from
the
event
to
continue
the
processing
yeah.
I
don't
know
if
you
look
to
me,
like
you,
have
something
else
or
to
add
something
that
you
want
to
say.
B
B
If
it's
an
http
request
or
something
we
don't
know
how
this
cloud
event
is
obtained.
Like
another
example,
I
give
it's
the
azure
storage
qsd
you
go
and
you
pull
the
queue
you
get
messages
from
curate.
So
basically
we
don't
know
if
there
is
a
request,
if
it's
incoming
request
and
probably
that,
though,
if
you
get
one,
it's
likely
to
be
unrelated
to
what's
inside
cloud
event,
at
least
in
many
cases
in
messaging
or
if
this
event
flew
through
multiple
hopes
right,
then
maybe
it
lost
contact
by
then.
B
So
I
think
there
are
two
different
cases,
and
it
feels
to
me
that
popular
one
that
it's
where
that
requesting
that
in
the
transport
layer,
the
context
and
trust
for
clear
is
unrelated
and
the
like.
But
the
think
you
are
continuing
your
logical,
your
application
context
and
it
flows
in
cloud
event.
B
So
if
we
choose
between
parent
and
link
that
sorry
that
the
message
event,
context
and
transparent
context,
message
context
seems
to
be
more
important
because
there's
the
continuation
of
what
you
edit
on
the
other
side,
I
think
at
the
same
time
there
are
cases
like
lab
hopes
or
eight
when
you
get
actually
an
http
request,
and
maybe
you
know
that
it
was
like
all
one
thing:
maybe
you
got
the
websocket
request.
B
You
would
still
get
mostly
the
same
trace
just
the
different
parent-child
relationships,
so,
okay,
anyway,
what
I'm
saying
that
it
seems
to
be
the
default
case?
Is
you
want
context
from
the
message?
Maybe
there
are
cases
where
you
want
the
transport
context
to
be
apparent,
but
I
don't
know
if
consumer
actually
knows
which
one
to
prefer.
A
I
I
have
a
remark
on
this
and
I
think
that's
a
great
example,
because
it
also
shows
us
some
kind
of
challenges
or
problems
that
we
will
have
with
the
messaging
in
general,
and
I
I
think
why
I
like
links
or
in
this
context,
is
because
links
are
very
composable,
so
with
links
can
just
be
like
if
we
would
build
a
whole
cloud
events
like
stuff
like
just
on
links,
then
they
could
easily
be
like
just
overlaid
on
hgb
or
other
asymptote
scenarios
and
it
will
kind
of
fit
on
that,
whereas
with
parenting
I
mean
we
see
here,
we
have
kind
of
a
bit
of
I
mean
I
wouldn't
call
it
a
conflict,
but
it
at
least
leads
to
a
for
maybe
some
people
confusing
restart
that
they
would
not
expect,
because
if
you,
if
you
model
something
with
links,
you
can
easily
kind
of
put
things
like
on
the
beginning
and
on
the
end
like
you
can
have.
A
If
you
want
an
instrument
instrumentation
layer,
you
can
have
kind
of
parents
for
this
linked
span
and
also
kind
of
children
for
the
link
kind
of
producer
span.
But
if
you
link
this
with
make,
this
is
a
parent-child
relationship.
A
It's
not
that
easy
to
extend
it
and
if
you
kind
of
would
have
additional
want
an
additional
parent
for
this
parent
span,
you
cannot
have
that
so
you
kind
of
basically
have
to
you
have
this
kind
of
then
this
split
here
that
looks
like
a
split
into
trace,
but
which
is
not
really
a
split,
because
you.
B
Would
have
split
either
way
right.
Whatever
you
do,
you
would
have
a
split,
because
you
have
two
related
things
and
you
can
say
that
the
message
context
is
apparent,
but
your
transport
context
is
a
link.
You
can
model
it
with
link
regardless,
it's
just
the
question:
what
gets
the
priority,
and
it
seems
to
me
that
the
logical
context
that
flows
is
an
event,
is
the
causation,
not
the
transport
call,
so
it's
just
it.
It
is
more.
A
Yeah
I
mean
I,
I
I
think
what
here
actually,
I
think
the
what
what
I
have
just
intuitively
would
expect
would
be
that
the
actually
the
transport
context,
which
is
this
http
here
and
this
http
receiver
span-
would
be
the
parent
of
this
cloud
events
process
span
here
and
then
there
would
be
a
link
from
this
process
to
this
create
span,
because
then
there
would
be
basically
a
a
kind
of
more
or
less
consistent,
parented
trace
and
there
would
still
be
the
connection
from
the
process
to
the
create
span,
because
here,
when
we
see
now,
we
have
basically
I
mean,
if
I
just
look
at
this
here,
it
looks
to
me
like
the
like.
A
There
are
two
kind
of
two
kind
of
basically
context
propagations
between
those
two
services
yeah
like
from
here
and
one
here
again,
which
might
be
confusing
for
people
who
don't
know.
What's
going
on.
It
looks.
E
No,
no,
it's
was
just
saying
that
I
showed
this
to
some
people
and
then
they
also
got
a
little
bit
confused.
They
said
like,
but
what
is
this?
Because
it
looks
like
the
the
top
one
fired
one
thing,
and
then
fire
fired
fire
like
another
another
request
or
and
so
that
it
looks
like
there's
two
things
happening,
but
even
with
links,
then
it
would
still
show
somewhat
similar
to
this
right.
E
Unless
you
do
like,
like
you
said
that
the
processing
is
is
a
child
of
the
receiver
span,
then
then
it
will
be
like
all
nested
correctly
yeah,
but
I'm
not
sure
if
that's
possible,
in
all
cases
right.
B
E
B
So
what
can
happen
if
we
make
the
the
process
a
child
of
receiver,
we
can
have
the
create
then
post.
Then
you
know
what
nothing
you
we
don't
own
telemetry
from
these
hopes
that
are
being
made
and
then
receive
some
grand
grand
grand
ancestor
right,
sorry,
gringo
and
child,
and
then
it
will
also
be
confusing.
Where
is
all
this
telemetry?
This
context
may
be
absolutely
unrelated.
E
Like
another
thing
that
I
also
thought
about
when
I
was
doing,
is
that
okay,
it's
kind
of
probably
maybe
a
far-fetched,
but
if
we
always
rely
on
the
context
that
that
that
are
that
is
in
the
event,
then
we
are
more
or
less
freed
from
from
having
auto
instrumentation
on
the
transport,
because,
for
example,
if
we
say
that
the
processing
should
use
the
active
span
that,
but
maybe
I'm
using
a
library,
for
example,
for
kafka,
which
is
not
instrumented
yet.
E
So
even
if
the
sender
sends
the
the
correct
headers,
then
it
will
be
lost,
because
I'm
not
the
the
library.
C
E
I'm
using
to
talk
to
kafka
is
not
auto
instrument
or
whatever
or
even
is
even
this
index.
In
this
example,
for
example,
that
is
just
http,
but
let's
say
that
the
processing
site
is
not
instrumented
with
with
auto
instrumentation,
then
then
it
will
have
a
broken
trace,
because
the
processing
side
will
not
be
related
to
the
crate.
Then,
because
there's
no
active
span
right,
so
I
think
it's
more
or
less
safer
if
we
always
use
the
one
from
the
event,
because
then
it's
it's
like
irrelevant.
E
If
the
transport
is
instrumented
or
not,
because
you
will
always
have
a
parent
child
relationship
from
the
moment
after
the
event
created
and
then
from
everything
that
happens
happened
after
this
event
was
created,
yeah
or
unless
we
do
something
like,
for
example
like
if
there
is
an
active
span,
then
use
the
active
span
or,
if
not
then
use
the
spam
from
the
event.
Something
like
that,
but
I'm
not
sure
yeah
if
having
either
or
or
like.
This
is
good.
E
F
F
A
That
is
why
this
discussion
is
great,
because
you
are
thinking
also
by
examples
here
like
would
be
great,
because
it
helps
us
a
lot
more
with
the
messaging
with
the
messaging
discussion.
But
one
thing
I
I
just
wanted
to
look
in
here,
because
we
were
talking
about
like
what
what
relationship
is
more
important.
A
I
think
we
fall
into
that
kind
of
mode
of
thinking,
because
most
of
the
backends
just
have
inferior
visualizations
currently
for
link
relationships,
but
but
I
just
wanna-
I
wanna
put
this
in
question
that
that
kind
of
the
decision
between
either
whether
we
do
parenting
or
linking
is
a
question
where
they
are
it's
kind
of
is
dependent
on
the
importance
of
the
relationship
between.
B
I
think
it's
not
just
the
the
visualization,
it's
basic
clearing
right.
So
it's
great.
If
you
can
query
all
your
logical
things
with
one
query,
unless
you
do
aggregation
or
something
like
that,
so
like
it's
the
the
causation
right,
when
you
have
a
parent,
you
know
it's.
Why
I'm
the
child
happened
right
and
it's
just
the
intuitively
clear.
D
I'd
like
to
add,
I
think
I
think
we
need
to
be
a
little
more
rigorous
than
just
if
it's
important
a
parent
child,
if,
if
it's
more
loosely
connected
links,
just
because
these
one
way
or
the
other,
these
visualizations
are
only
going
to
work
one
way
and
we
need
users
of
open
telemetry
tracing
to
have
a
a
mental
model
that
they
can
rely
upon.
D
They
so
they're
gonna
have
some
expectations
about
what
what
these
relationships
mean.
Sort
of
like
what
I
was
saying,
you
know,
like
people,
have
an
expectation
built
up
in
their
head
about
what
the
parent-child
relationship
means,
and
I
think
we
just
need
to
make
sure
that
we
stay
consistent
with
that
one
way
or
another.
D
This
was
a
thing
that
came
up
when
we
were
looking
at
http
stuff
and
like
using
links,
and
there
was
one
way
that
we
did
it
that
logically
made
sense,
but
it
was
a
little
bit
different
than
what
people
were
used
to,
and
so
I
think
it
could
just
be
easy
to
confuse
the
end
user
here
if
they
need
to
understand
what
particular
type
of
thing
they're
looking
at
ergo.
This
is
what
links
mean
in
this
case,
or
something
like
that,
if
that
makes
sense,.
A
Yes,
I
mean
that
that
would
be
a
great
kind
of
transition
to
the
other
discussion,
because
I
just
added
something
to
the
other
document
about
that,
but
just
want
to
make
sure
if
there
is
because
I
think
now
what
we
said
here
is
that
we
will
look
at
additional
examples,
maybe
next
week,
if
somebody
has
time
to
come
up
with
those
transforming,
if
that's
okay
with
everybody,
if
there's
like
more
things,
you
wanna
discuss
for
this
cloud
events,
pr.
A
Awesome
thanks
then,
and
luke
miller,
for
that
and
I
think
it
I
said
it's
a
great
transition
to
the
other
discussion,
because
here
I
just
made
some
notes
what
we
discussed
last
week-
and
I
tried
then
from
from
our
discussion
to
distill
some
kind
of
principles,
which
is
a
pretty
a
pretty
fancy
word,
but
just
some
principles
that
will
help
us
to
kind
of
we
love
will
give
give
us
some
guidance
when
designing
a
consistent
messaging
model,
and
there
is
two
I
came
up
with
and
both
are
kind
of
related
to
links
and
the
first
one
and
yeah,
and
I
would
like
to
contest
those
if
you
don't
agree
or
have
a
have
doubts
there,
but
the
first
one
is
that
we
kind
of
came
to
like
we
put
it
out
there
last
time
that
we
said.
A
This
basically
had
the
main
reason
that
when
modeling
I
mean
synchronous
transactions,
I
think
it's
clear
that
we
want
to
have
parent-child
relationships
there,
because
that
is.
I
think
that
is
the
obvious
thing
obvious
thing
to
do.
A
For
asynchronous
transactions
which
messaging
transactions
like
producer,
consumer
scenarios
by
nature,
are
we
brought
up
the
point
that
we
have
to
be
very
flexible
regarding
time
constraints?
So
we
cannot
assume
that
kind
of
the
consuming
transaction
happens
anywhere
close
to
the
producing
transactions
they
might
in
in
many
scenarios.
But
we
cannot
assume
that
and
yeah
when
using
parent
trial
relationships
for
modeling
those
there
might
be
in
a
single
trace,
really
big
gaps
like
when
you
think
about
certain
messaging
scenarios,
I
mean
you:
might
there
might
be
hours
or
days?
A
I
mean
messages
might
be
consumed
multiple
times
like
the
first
time,
maybe
immediately
a
second
time
like
hours
later,
so
that
might
really
distort
like
a
single
trace
when
you
have
these
things
modeled
as
parent-child
relationships
there
are.
That
was
just
the
one
thing
that
came
up
last
week.
I
put
it
in
here.
There
might
be
other
other
things
to
think
about
pros
and
cons,
but
I
just
put
it
out
there
like
for
sparking
a
discussion,
and
the
second
point
here,
horrible
somehow
related
to
links
where
we
kind
of
put
out
the
question
here.
A
But
how
do
we
handle
this?
This
lack
of
backhand
functionality
when
it
comes
to
open
telemetry
capabilities
links,
for
example
like
most
back-ends,
currently
don't
support
links,
and
we
kind
of
put
it
out
there.
So
we
said
yeah.
We
want
to
leverage
existing
open,
telemetry's
capabilities
where
it
makes
sense,
regardless
of
backhand
limitations.
A
So
even
if
there
is
no
again
like
extrapolating
this
to
links
again,
if
there
is
no
decent
link
support
yet
in
most
backends,
this
should
not
stop
us
from
adopting
links
as
kind
of
a
tool
to
to
in
the
messaging
semantic
conventions,
and
we
just
yeah
expect
kind
of
the
backhands
to
catch
up
there
at
some
point
because
yeah
it
will
not
work
the
other
way
around.
It
will
not
be
the
case
that
all
I
can
still
wait
until
all
backhand
support
links
and
then
we
kind
of
design
according
to
that.
A
So
that
was
just
two
kind
of
kind
of
principles.
I
kind
of
tried
to
distill
from
last
week's
discussions
and
just
wanted
to
put
it
out
there
for
for
being
challenged
or
having
some
feedback,
if
you
think
that
makes
sense
or
does
not
make
sense
in
this
in
the
way
I
put
it
here,.
B
I
have
a
couple
of
comments
regarding
the
first
one
and
they
are
pretty
much
similar.
I
I
think
it's
great
if
we
send
one
message
asynchronously
to
be
able
to
vary
everything
related
to
it,
with
one
trace
without
using
links.
I
think
this
is
a
great
user
experience
for
those
who
don't
have
fancy
backhand
right
and
it's
it
may
be
easier
for
beckons.
I
don't
know,
and
the
other
comment
that
the
the
concern
that
huge
gap
will
distort
one
trace.
B
D
B
Beckons
will,
but
if
you
start,
I
don't
know,
let's
say
you
store
in
a
database.
Maybe
you
need
to
join
based
on
links
and
not
all
the
database.
Nosql
database
support
joins
right
and
for
users,
it's
harder
to
write
a
query
that
they,
if
they
want
to
export
this
data
somewhere,
where
they
can
do
manual
some
custom
visualizations.
D
I
so
I
wonder
I'm
trying
to
think
here
about
ways
we
can.
We
can
make
it
more
efficient
for
certain
backends.
I
do
like
the
consistency
of
of
keeping
these
these
well.
I
guess
I
should
say
I
think,
there's
a
good
important
case
for
consistency
here
and
then
it's
it's
on
us
to
to
figure
out
how
to
how
to
make
that
effective.
D
It's
a
little
bit
tricky.
I
don't
quite
know
exactly
how
we
would
implement
it,
because
you
can
use
links
for
both
fan
out
and
fan
in
and
things
like
that.
D
Of
some
kind
that
you
would
attach
to
to
all
of
these
different
lengths,
you
know
another
way
of
saying
it
is
if
it,
if
it
is
possible
to
put
them
all
into
a
single
trace,
then
that
implies
it
is
possible
to
to
pick
one
trace
id
to
use
a
lookup
as
a
lookup
for
for
all
of
the
trace
and
all
of
its
related
links.
D
But
I'm
not
sure
I
I
just
feel
like
there's
a
lot
of
scenarios
where
that
that
isn't
quite
the
case,
because
we're
talking
about
graphs
that
aren't
trees,
essentially
in
a
number
of
number
places.
So
that's
that's
the
tricky
bit.
B
So
I
I'm
okay,
I
think
the
consistency
is
a
very
strong
argument
and
it
simplifies
basically
everything
for
everyone,
maybe
not
users,
maybe
the
the
way
for
me
to
think
about.
It
is
as
we
progress
and
we
implement
some
prototypes,
I
would
play
with
them
and
they
will
see
if
something
breaks,
because.
D
D
When
we're
doing
this
and
yeah,
I
wonder
if,
as
long
as
we
can
say
propose
a
it
would
be
a
slightly
more
complex,
sql
query
right,
but
if
we
can
propose
here
here
is
a
sql
query
that
you
can
make
to
find
a
trace
and
all
of
the
links
related
to
this
trace,
like
a
recursive,
sql,
query
of
some
kind
and
just
have
that
published
as
well,
like
some
amount
of
guidance
there,
like.
D
Maybe
that's
that's
sufficient,
like
we
shouldn't
just
leave
people
hanging,
but
I
think
we've
gotta,
we
gotta
we
gotta
figure
it
out
like
because
otherwise,
they're
gonna
be
stuck
whenever
we
use
links,
they're
gonna
be
stuck,
and
even
if
we
find
some
cases
where
we
make
it
nicer
for
them,
because
we
avoided
using
links
like
we're
still
going
to
be
using
links
elsewhere.
So
I
think
we
should.
D
You
know,
like
sql
databases
are
not
necessarily
the
right
solution
for
for
storing
all
of
this
stuff,
but
if
we
could
provide
people
with
with
schemas
for
like
here
is
a
decent
way
to
to
store
this
data.
You
should
you
know,
make
a
lookup
table
here
and
you
should
store
all
the
actual
traces
somewhere
over
here,
and
this
is
decent.
Maybe
that's
like
a
side
project.
We
could
be
working
on.
A
Yes,
I
think
basic
ring,
fearing
I
mean
you
would
have
some
kind
of
a
two
pass
query
to
get
like
all
the
links.
Basically,
that
are
direct
links
from
the
original
trace.
I
think
that
is
the
additional
cost
that
you
will
have.
I
mean
you
first
will
would
need
to
query
all
the
spans
with
a
certain
trace
id
and
then
in
the
second
pass.
A
D
D
And
maybe
it
goes
without
saying,
but
I
do
think
we
need
to
be
crystal
clear
that
even
with
links,
we
are
still
creating
an
acyclic
graph
right
like
I,
I
don't
know
how
we
would
end
up
exactly
in
a
situation
where
we
created
a
cyclic
graph
of
some
kind.
But
I
think
that's
a
thing
we
should
be
aware
of,
avoiding
because
we
want
to
support
a
recursive
querying
model
because
that's
going
to
be
the
way
you're
gonna
have
to
write
it
in
some
some
languages
or
some
some
databases.
A
Yes
and
basically,
interestingly,
what
we
are
talking
about
now,
it's
also
the
second
point.
So
it's
basically
the
question
yeah
when
we
are
using
games,
do
we
take
like
limitations
on
on
backhand
side
into
account,
and
I
mean
somehow
those
those
two
points
are
are
linked,
no
pun
intended
in
that
way.
D
I
I
think
I
think
we
need
to
propose
a
general.
We
need
to
have
a
general
model
of
computation
when
we're
talking
about
this
stuff,
but
we
shouldn't
be
limited
by
the
current
capabilities
of
you
know.
Specific
systems,
like
I
think,
like
you,
were
saying
before
we
should,
if
we
wait
for
tracing
systems
to
implement
links
before
we
give
them
like
it,
it's
like
chicken
egg
right
like
we
just
have
to
do
this
and
they'll
catch
up.
If
we
don't
do
it,
they'll
they'll
never
they'll
never
implement
it.
A
A
When,
in
what
situations
is
it
justified
to
use
something
that
is
inefficient?.
F
So
I
think
we
all
agree
that
for
batching
we
have
no
other
solution
in
mind
than
using
links
so
for
batching
we
will
use
links.
So
the
whole
discussion
is
about
one
to
one
where
you
have
one
sender
and
one
receiver,
and
we
just
focus
on
this
specific
case,
and
I
wonder
how
common
it
is
because
if
we
agree
that
we
will
use
links
for
batching,
then
it's
a
different.
D
Yeah-
and
I
I
worry
just
with
the
decoupled
nature
of
messaging
systems
like
how,
how
can
you
know
potentially,
I
suppose
the
receiver
knows
that
it's
one-to-one
and
could
choose
to
to
just
create
a
trace
parent,
but
it
seems
it
seems
a
little
inconsistent
and
I
don't
know
I
worry
about
it.
A
little
bit.
A
I
I
think
it
is
inconsistent
in
a
way
I
mean
we
looked
at
order.
Examples
above
and
we
basically
remember
like
we
have
lots
of
different
kind
of
ways
to
link
things
together.
Sometimes
we
have
links.
Sometimes
we
have
parents
of
the
one
or
the
other
way
here
with
parenting
end
links,
and
here
we
just
have
parenting
in
the
first
two
scenarios
and
yeah.
A
I
think
here,
consistency
is
another
point
here
that
is
taken
into
consideration,
so
I
mean,
of
course
the
simplest
solution
is
then
to
say:
yeah
we
use
links
all
the
time,
and
that
is
consistent,
but
yeah
as
we
discussed
before.
There
are
other
drawbacks
to
that.
A
So
I
mean
I
I
think,
and
for
for
next
time
I
will
just
try
at
least
for
this
links
or
not
links
question
to
try
to
come
up
with
a
list
of
kind
of
pros
and
cons
that
we
have
and
that
we
kind
of
kind
of
touched
on
now,
and
maybe
that
will
kind
of
give
us
a
clearer
picture
of
what
are
kind
of
the
drawbacks
or
costs
or
benefits
of
each
of
the
approaches.
D
And
I
so
I've
asked
some
people
at
google
to
do
this,
but
maybe
for
others
is
there
a
way
we
can
make
this
lynx
model
more
efficient
or
potentially
at
least
model
its
expected
efficiency?
D
I
think
that's
that's,
maybe
just
if
it's
something
we're
going
to
be
concerned
about
if
efficiency
is
something
we're
concerned
about
it's
good
to
to
quantify
that
in
some
way,
and
if
there's
I
I'm
not
an
expert
at
graph
databases,
I
don't
know.
If
there's
some
way
we
could
improve
on
our
very
simplistic
form
of
linking
that
would
would
make
things
more
efficient
or
if
the
reality
is.
C
B
I'm
sorry
we
allow
links
to
be
passed
only
when
spawn
is.
B
Makes
sense
because
of
sampling,
but
at
the
same
time
like
when
we
receive
things,
don't
know
what
we
are
going
to
receive.
So
basically
we
we
cannot
properly
without
hacking
model
the
span
which
receives
stuff,
and
I
think
it's
just
a
part
of
this
discussion,
how
we
have
links
efficient
and
also
working
for
instrumentations.
D
A
Yes,
that
is
on
the
I
think
that
is
out,
let's
go
for
1.0,
but
what
I
will
also
do
for
next
week.
I
will
because,
on
on
azure,
monitor
side
like
the
backhand
supports
links
and
the
visualization
supports
links
too,
and
I
will
try
to
reach
out
to
people
there
and
trust
your
inquire
about
about
the
additional
cost
that
that
causes
for
them
on
query
site.
I
will
ask
them
if
that
is
kind
of
a
significant
or
if
that
can
be
treated
as
a
networker.
A
D
Thanks
for
driving
this
forward,
johannes.
A
No
no
problem,
so
I
think
I
think,
for
context
propagation.
I
think.
Actually
that
is
probably
one
of
the
or
maybe
the
biggest
question
we
need
to
answer
so
yeah.
Let's
keep
on
that
and
thanks
for
the
discussion
today,
I
think
it
was
great
progress
and
also
thanks
for
joining
miller
for
the
work
on
the
on
the
cloud
event
stuff,
because
it's
basically
the
same
question.
A
There
and
if
we
would
have
some
examples
on
cloud
event
site
next
week
and
then
I
will
try
to
come
up
with
like
a
list
of
pros
and
cons
here.
I
think
that
would
be
a
great
I'll.
E
See
if
I
can
make
a
sample
app
that
maybe
has
the
asynchronous,
or
at
least
not
direct,
direct
sender
and
receiver,
so
we
can
see
maybe
at
least
see
how
the
trace
looks
like
with
links
and
in
some
place.
Yeah.
B
A
A
Oh
sorry
for
interrupting,
but
I
think
here
actually
it
would
be
nice
also
to
have
these
different
scenarios
where
we,
for
example,
I
think
there's
this
one
point
where
we
say:
if
multiple
events
are
processed
together,
then
we
need
to
have
places
anyway.
I
think
it
would
be
nice
to
see
kind
of
also
the
different
scenarios
that.
E
A
E
I
was
thinking
about
in
this
document
writing
the
same
like
scenarios
like
in
in
the
otep
that
that
was
there
or
in
the
in
the
current
messaging
that
you
have
like
some
real
scenarios
yeah.
I
think
that
makes
sense,
but
I
think
once
we
figure
out
the
context,
then
I
can
write
because
right
now,
probably
it
will
be
unanswered
anyway,
but
yeah,
I
think
so
makes
sense.
B
And
I
will
prepare
an
example
with
some
azure
service
in
between,
so
we
can
see
like
this
multiple
hubs.
B
I
want
to
call
out
one
thing:
I
don't
think
we
need
a
discussion
if
you
can
switch
back
to
the
pull
request
with
cloud
events,
so
we've
been
chatting
about
having
the
cloud
events
in
the
span
name
right,
because
users
would
want
to
know.
What's
that,
it's
basically
the
layer
thing
I'm
trying
to
push
so
every
span
should
know
what
it
is.
So
users
can
know-
and
we
are
currently
put
put
it
in
the
name,
but
I
hope
we
can
find
more
consistent
place
somewhere
to
put
things
like
that.
A
I
think
put
together
name
currently
is
the
right
decision,
because
yeah
it
helps
here
to
see
okay,
yeah,
that's
http,
that
is
cloud
events,
but
yeah.
I
I
get
the
point
that
it
should
be
more
kind
of
a
rigid
and
logical
way
to
store
the
type
of
spam,
make
sense.
A
Awesome
then,
here
we
have
to
end
earlier
anyway,
because
I
think
there
are
not
no
additional
meeting
slots
yet
so
thanks
everybody
for
the
discussion
today.
That
was
very
productive.
I
think,
and
thanks
for
the
work
you're
doing
on
that
and
see
you
all
next
week,
hopefully.