►
From YouTube: 2022-03-31 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
A
Okay,
so
is
not
here.
I
wanted
you
to
ask
him
some
question
about
it,
but
he
set
up
a
project
board
for
us
and
I
I
added
stuff
to
this
project
board.
So
that's
how
it
looks
like
currently.
A
So
what
I
did
here,
like
daddy,
created
those
categories-
and
I
just
looked
into
this
basically
had
this-
let's
see
here
this
this
list
of
discussion
items-
and
I
just
turned
this
basically
into
items
for
here-
mostly
those
are
draft
items,
because
no
issues
exist
for
them
and.
A
So
basically
that's
what
we
are
currently
working
on
this
old
tap,
we're
stabilizing
my
semantic
conventions,
and
then
I
created
like
this,
a
more
fine-grained
issue
that
we're
talking
about
settlement
instrumentation
and
we
still
have
to
wrap
up
the
pull
based
consumer
instrumentation,
and
this
depends
on
the
links
and
processbands
channel
attributes
and
then
messaging
system
specific
attributes,
that's
basically
from
the
from
the
other
open
items
list
just
converted
it
to
here,
and
then
I
added
issues
in
the
specification
repository
that
are
related
to
the
messaging
semantic
conventions.
A
So
some
of
them
we
should
more
or
less
just
automatically
resolve
by
the
conventions
that
he
can
come
up
and
others
we
might
need
them
to
discuss.
Probably
when
we
get
two
attributes,
many
of
them
are
related
to
attributes
here.
There's
an
example
missing,
that's
also
related
to
attributes,
and
that
is
also
attributes
and
other
stuff,
just
hint
at
inconsistencies
in
the
messaging
semantic
conventions
or
for
messaging
semantic
conventions
with
other
systems
or
other
semantic
conventions
areas.
A
That
is
basically
I
mean
with
two
it's
more
or
less
post
v1.
So
after
the
first
stable
version
or
or
more
or
less,
it's
like
even
it's
out
of
scope
for
the
first
stable
version.
That's
how
I
see
those
items
here
and
that's
not
yet
in
any
kind
of
order,
but
but
also
just
taking
over
from
the
other
list
what
we
had
and
also
some
issues
here.
It's
the
details
about
context,
propagation
for
the
individual
protocols
that
ties
into
the
intermediary
instrumentation.
A
A
The
other
is
about
the
excessive
amounts
of
recorded
data
that
basically
ties
into
sampling,
which
we
also
put
post
v1
and
the
last
one
yeah
last
but
not
least,
metrics
for
semantic
conventions
for
metrics
for
messaging
systems.
That's
also
basically
post
v1
for
the
tracing
stuff,
obviously-
and
here's
just
here-
some
stuff
that
we
already
finished
discussing.
A
So
if
you
have
any,
if
you
have
any
kind
of,
I
think
anything
is
missing,
feel
free
to
edit.
Here
I
think
everybody
can
create
draft
items
here
so
yeah
that
can
be
a
collaborative
effort,
so
feel
free
to
add
things
here
or
shove.
Things
around.
A
A
I
see
this
is
kind
of
orthogonal,
so
I
think
it
would
still
be
very
helpful
for
us
to
have
some
kind
of
of
sponsor
of
connection
to
the
technical
committee
to
a
bit
of
oversight
from
their
side
of
our
work,
but
yeah,
maybe
we'll
join
later.
Otherwise
we
can
raise
it
with
the
next
time.
A
I
pinged
octon
again
yesterday.
He
said
he
might
join,
maybe
comes
later.
So,
let's
just
let's
maybe
very
many
joints
later.
Maybe
we
can
go
to
this
point,
but
then,
if
nobody
else
has
anything
else,
maybe
we
can
continue
discussing
the
settlement
scenarios
based
on
based
on
the.
A
But
I
think
I
found
a
point
because
I
tried
to
figure
out
like
the
just
to
this
first
point
here:
try
to
figure
out
like
how
those
those
scenarios
overlap
and
actually
wonder
where
we
have
your
premessage
settlement
and
checkpoint
settlement
and
auto
settlement
and
for
auto
settlement.
I've
wondered
how
that
overlaps
or
if
there
overlaps
at
all
with
per
message,
settlement
or
checkpoint
settlement,
I
mean
is
auto
settlement.
Do
we
always
say
this
is
a
permissive
settlement,
or
can
it
also
be
a
checkpoint
settlement
or
is
it
its
very
own
thing?
C
Actually,
the
discussion
can
we
can
have
the
the
discussion
both
for
the
api
level
and
for
the
communication
level,
because,
if
we're
instrumenting
a
client
like
a
messaging,
a
client,
a
messaging,
a
package
in
the
in
a
language,
then
this
package
it
has
like
two
sides.
There
is
the
way
that
the
user
interact
with
the
package,
the
public
api,
the
methods
that
is
calling-
and
I
don't
know-
like
the
user
facing
their
side
and
there's
the
transport
facing
side
of
the
messages
that
are
being
communicated
to
the
broker.
C
So
what
I
wrote
here
is
the
perspective
from
the
user
side.
So
if,
if
there
is
like
a
no
settlement
or
auto
settlement,
like
the
underlying
communication
layer
could
generate
some
some,
like
transport
layer,
their
messages
to
to
settle
their
stuff,
but
the
user.
C
It's
not
requesting
it,
it's
not
a
part
of
his
source
code.
So,
like
the
auto
settlement
and
the
like
the
message
and
checkpoint
settlement,
there
are
different
things
on
the
api
level.
They
could
be
the
same
thing
on
the
transport
level
and
sometimes
it's
even
there's
no
way
a
message
is
involved
like
in
a
rabbit.
You
can
ask
the
vocal
to
where
for
no
settlement,
and
then
it
will
auto
settlement.
The
message
in
the
broker
like
it
doesn't
even
involve
any
communication
with
the
client.
A
A
I
see
what
you
mean
so
from
the
user
point
of
view,
when
there
is
other
settlement
in
place
for
the
user,
it
doesn't
really
matter
whether
it's
per
message,
settlement
or
checkpoint
settlement,
because
it's
all
automatic
anyway
and
the
user
doesn't
see
anything
that
makes
sense.
I
still
think
it
might
make
sense
so
on
the
on
the
on
the
instrumentation
level,
because
in
the
other
settlement,
when
we
create
a
span,
there
might
be
like,
for
example,
different
attributes
depending
on
but
rory
look
miller,
it
seems
to
cut
you
off.
B
That's
okay,
so
I
think
last
time
we
discussed
that
if
all
the
settlement,
even
if
it's
and
place
it
for
users,
but
if
it
involves
an
arpeggio
call,
if
it's
not
fire
and
forget
local
thing
right,
we
still
want
it
because
it
tells
okay.
What
that
it
was
settled
that
all
that
configuration
was
applied
or
the
offset
or
the
some
information
about
the
message.
Maybe
some
attributes
anyway.
B
B
A
If
I
understood
correctly
would
be
settlers,
then,
basically,
then
the
sdk
more
or
less
internally
settles
the
messages
and
then
the
sdk
either
creates
what
we
define
whatever
we
define
for
a
message
settlement
or
for
trackpoint
based
settlement,
and
just
the
user
doesn't
trigger
this
bank
creation,
but
it's
just
like
the
sdk
internally
basically
creates
those
bands.
So
whatever
we
define
for
those
two
points
here.
C
What's
the
source
of
the
settlement
span
like
if
it's
something
internal
or
if
it's
an
api
call,
I
want
to
describe
a
lot
of
our
users,
our
developers
and
they
consume
telemetry
data
for
to
search
for
issues
in
their
business
code
and
then
the
thing
that
is
most
useful
for
them
is
to
to
have
the
api.
Like
they
look
at
the
code,
they
see
that
they
call
the
method
and
they
know
that
they
called
it,
because
it's
in
their
code
and
then
for
sure.
I
think
this
should
always
be
instrumented.
C
So
if
the
developer,
the
software
engineer
is
like
invoking
something
in
his
software,
then
he
wants
to
see
it
in
the
trace
and
regarding
the
transport,
I
agree
with
you
that
there
is
a
lot
of
value
to
it.
If
things
are
happening
under
the
wood
and
the
developer
is
not
even
exposed
to
the
internal
logic,
but
it
is
possible
that
it
creates
issues
in
its
application
or
in
the
message
broker.
I
don't
know
any
anyone
has
its
own
motivation,
but
but
there
should
be
distinct.
C
B
So
I
don't
call
a
subtle
call
or
any
subtle
method
in
my
code,
but
I
see
a
processing
span
and
then
I
see
some
http
random
spans
that
are
not
wrapped
that
are
related
to
settlement
right.
So
what
I'm
talking
about,
not
the
http
layer
but
the
api
layer,
it's
just
the
api
user
didn't
call
directly
and
then,
if
we
don't
rub
those
http,
spams
or
vlogs,
it
will
be
very
confusing.
B
C
C
D
If
I'm
understanding
what
what?
What?
What
do
you,
what
you
guys
are
saying,
I
I
I
picked
something
that
that
that
I
mean
said
that
so
like
there's,
two
types
that
say
settlement,
I
I
as
a
as
a
the
app
developer.
I
can
call
the
method
on
the
sdk
to
say,
settle
this
and
then
it
can
also
be
settled
without
me
doing
anything
by
the
sdk.
So
the
sdk
can
do
it
automatically,
and
I
think
what
amir
was.
D
Yeah,
I
think
I
mean
I
don't
know,
I
guess
it
depends
how
searchable
things
you
think
things
are
right,
but
for
for
messages
we
have
the
the
the
the
is
it
source,
what's
called
or
the
forgotten
the
name
of,
but
where
you
say
it's
producer
or
consumer.
D
So
it
could
be
something
similar
right
for
for
for
this.
For
this
this
scenario,
so
the
span
could
have
could
have
something
that
indicates
that
who
called
it
or
or
was
the
creator
of
it
or
something
like
that,
and
if
we
have
the
http
http
call
because
of
the
the
settlement
involves
a
rpc
call,
then
this
pen
will
be
nested
or
be
a
child
of
the
sediment
span
right.
So
then
we're
good
again.
B
Yes-
and
it
would
be
great,
but
I,
like
my
checkpoint
api
lives
in
one
library,
implementation
of
where
it
lives
in
second
library
and
the
pattern
where
we
process
it.
So
I
can't
ever
be
sure
if
this
method
was
called
by
another
sdk,
I
own
or
by
user.
D
D
C
For
sure,
when
it's
not
possible,
then
we
have
nothing
to
do.
A
Yeah
I
mean
what
what
one
can
always
do.
One
can
just
kind
of
in
in
indiscriminately
say
that.
Okay,
those
are
kind
of
the
settlement
spans
that
you
need
to
create.
Whenever
settlement
operation
takes
place,
no
matter
whether
the
user
triggers
it
or
whether
the
sdk
triggers
it,
but
then
how
you
kind
of
how
you
put
those
bands
or
how
to
spend
to
be
in
the
trace
that
is
then
more
or
less
sdk
specific.
A
B
A
Leave
that
up
to
the
basically
unspecified
so
that
for
each
kind
of
use
case
or
free
trusty
case,
they
could
kind
of
decide
what
best
makes
sense
for
them,
which
leads
to
some
kind
of
maybe
inconsistencies.
If
you
want
to
call
it
like
that,
but
might
also
help
to
come
up
with
a
solution
that
makes
sense
in
most
scenarios.
C
A
Basically
covers
the
operation
of
of
of
handing
over
the
message
to
the
to
the
messaging
sdk
that
is
for
the
published
span
handles,
and
I
mean
then
the
sending
on
the
wire.
That
is
again
a
different
thing
that
can
happen
like
independently
actually
of
this
publish,
they
might
be
cached
and
then
sent
send
at
a
later
point.
But
for
this
publish
measure
message,
it's
basically
there's
one
point
in
your
application
or
code.
A
So
I'm
not
sure
if
this
I
mean
once
one
more
thing,
I'm
interested
in
maybe
army
and
luke
miller.
You
can
give
more
insight
in
that.
I
wondered
how
how
popular
those
other
settlement
scenarios
are.
I
mean
I
mean
you
looked
at
a
lot
of
kind
of
sdks
is
that
kind
of?
Is
that
more
more
less
of
an
exception
that
there
is
other
settlement
or
is
that
available
is
most
sdks?
You
looked
at.
C
You
register
a
callback
and
then
this
callback
either
terminates
with
no
arrows
or
foreign
exception,
and
the
sdk
is
responsible
to
transform
this
signal
into
a
settlement.
So
there
are
a
lot
of
libraries,
at
least
in
the
node
python,
ruby
languages
that
act
like
this.
It's
I
think
it's
very
convenient
to
users.
They
like
it
because
they
don't
have
to
think
about
settlement.
E
Yeah,
I
think
my
experience
auto
settlement
is
very
common
as
well.
It's
a
concept
in
jms,
which
is
a
bit
of
a
dinosaur,
but
a
lot
of
things
are
are
in
many
ways:
modeled
off
of
it,
and
I
and
and
this
the
paradigm
of
having
applications,
register,
callbacks
and
automatically
settle
in
the
sdk
is
quite
common.
B
Same
here
like
we
have
a
processor
api,
where
you
can
create
a
client
and
give
a
call
back
right
and
you
can
configure
if
it
will
auto
settle
or
you
will
set
both
yourself.
And
it's
not
only
important
to
know
like
there
is
some
logic
created.
For
example,
it
tries
to
process
messages
message
twice
and
then
it
abandons
it
or
sends
to
that
letter,
q
or
something,
and
then.
B
Basically,
it's
also
important
what
kind
of
settlement
it
was
and
if
you
misconfigure
it,
you
can
end
up
with
a
quite
a
different
thing
and
if
you
don't
know
which
settlement
calls
has
became
made
you're
kind
of
lost.
The
gms
example
is
also
it's
an
interesting
one.
So
the
gms
is
an
abstraction.
You
can
run
of
different
libraries
like
revitampu
or
azure
ones.
I'm
sure
some
amazon
libraries
can
also
support
gms.
But
basically
you
want
to
know
what
happens
under
the
hood
for
monitoring
purposes,
and
you
never
call
any
of
these
libraries
directly.
B
You
call
them
strategies
obstructions
and
I
think
this
this
idea
that
the
spans
should
all
originate
from
code
it.
It
doesn't
work
in
all
cases
it's
great,
but
we
should
not
limit
ourselves
to
only
those.
C
Totally
agree,
I
just
had
been
bad
experience
with
watching
our
users
look
at
places
and
they're
like
they
don't
have
easy
way
to
distinguish
their
business
calls
from
like
internal
stuff.
Suddenly
you
have
some
ready
spans
like
flying
around
and
you
don't
know
what
they
mean,
but
because
your
code
didn't
create
them.
So
my
motivation
is
that
the
implementers
of
instrumentations
will
be
able
to
mark
the
spans,
so
it's
easier
to
understand
what
causes
them.
C
A
I
mean
what
we
could
do
for
the
auto
settlement.
I
mean
for
because
I
think
the
other
settlement
is
something
that's
relevant
to
the
to
the
push
scenarios.
A
A
I
mean
that
we
could
do
to
to
avoid
like
those
free
floating
spans,
but
it's
still.
I
think
it
could
be
a
pretty
nice
solution.
It's
just
it's
it's
more
spans,
but
I
think
it
improves
clarity
and
it,
I
think
the
downside
to
see
is
still
that
amy
said
yeah,
you
don't
know
which
spans
kind
of
corresponds
to
use
operations
and
which
spans
correspond
to
sdk
internal
operations.
C
I
want
to
suggest
another
option:
it's
something
that
I
implemented
in
a
rabbit
instrumentation.
You
know,
because
we
have
this
callback
and
this
callback
is
scoped
by
the
delivery
span
and
the
auto
settlement.
Logic
is
like.
If
this
callback
succeeded
and
the
message
is
settled
and
if
not,
then
the
message
is
knocked.
C
So
what
I
did
is
I
just
used
the
spam
for
the
deliver
or
a
process.
It's
currently
called
process,
but
what
I
mean
is
the
deliver
and
then,
by
the
result
of
this
spam,
you're
able
to
tell
if
the
message
was
settled
or
not,
and
we
might
like.
I
imagine
that
we
can
take
this
deliver
span
and
add
an
attribute
that
says:
auto,
settle
or
auto
settle
equals
auto
or
something
like
this,
and
then
we
can
like
not
in
not
even
create
a
settlement
span
but
merge
them
both
into
a
single
one.
B
I
think
the
approach
we
discussed
last
time,
it's
like
it's
either
or
right
it's
up
to
sdk,
depending
on
the
conditions
we
will
list
to
create,
auto
settlement
span
or
not
to
right,
and
then,
if
not,
then
yeah
that
would
be
awesome
to
have
either
I'm
not
sure
status
is
is
a
good
thing
for
it,
because
we
will
have
to
agree
on
different
statuses,
because
settlement
is
not
binary
choice
right.
B
There
are
different
sorts
of
how
message
will
end
and
then,
in
this
case
maybe
it's
an
attribute
or
an
event
right
event
is,
is
even
better
because
we
can
say
when
settlement
started
at
least.
B
A
I
mean
the
the
other.
I
think
we
discussed
the
dust
and,
through
the
other
downside
to
this
approach,
is
that
then
this
delivers
span
it.
The
the
duration
of
this
deliver
span
will
be
extended
over
the
extent
of
over
the
duration
of
the
callback,
because
settlement
will
basically
happen
when
the
callback
ended
and
then
the
delivered
spam
must
not
be
ended
when
the
callback
ends.
It
must
only
be
ended
when
the
settlement
is
done.
B
C
So
I
think
it's
a
we're
again
at
the
question
of
like
we
have
two
levels
of
set
elements
we
have.
The
settlement
of
the
user
logically
asks
the
sdk
to
settle
the
message,
signaling
the
the
sdk,
to
settle
the
message,
so
it
can
be
either
by
a
api
call
or
automatically,
and
then
there
is
the
like
wire
the
spam
that
actually
is
doing
the
rpc.
C
C
To
to
instrument
the
actual
wire
messages
that
are
exchanged
with
the
bottom.
A
Yeah,
I
I
think
the
delivers
that
the
settlement
spend
that
we're
talking
here.
I
think
those
are
never
transport
level
spends,
so
I
think
we
will
never
create
like
we
will
never
ask
for
creating
mqb
or
http
spends.
I
think
the
settlement
span,
even
in
the
case
of
other
settlement
here
those
are
always
kind
of
more
or
less
logical
spans,
just
showing
us
the
duration
of
the
settlement
operation.
A
So
even
when
we
have
this,
basically
the
sdk
creating
the
settlement
span
and
making
it
the
child
of
the
deliver
span.
I
think
that
will
not.
We
will
not
ask
for
creating
http
or
mqb
spends
there.
That
will
just
be
a
spam.
Basically,
that
covers
the
logical
duration
of
the
settlement
operation
and
then
later
on,
http
and
mqb
spans
might
be
children
of
this
settlement
span,
but
I
think
when
we
extend
the
deliver
span
like
to
orphan
kill
settlement,
I
kind
of
agree
with
luke
miller
that
having
this
ban
makes
sense.
A
E
But
but
if,
if
it's
sort
of
a
local
operation,
that's
effectively
zero
length
or
close
to
zero
length,
that's
where
we
were
talking
about
last
week
that
we
wouldn't
want
to
require
the
creation
of
the
settlement
span.
E
In
that
case,
and
and
if,
if
you
wanted
the
deliver
process
span
for
for
auto
settlement
to
cover
settlement,
you
could
maybe
add
it
like
just
to
show
that
a
little
bit
of
time,
you
might
add
an
event
or
something
to
that
span,
to
show
when
processing
finished
and
then
end
the
span
after
you've
called
the
internal
method
to
settle.
Maybe
maybe
you
should
just
end
it
and
don't
worry
about
the
settlement
at
all.
A
So
just
following
up
would
this
make
sense
for
everybody
that
in
case
yeah,
there
is
a
rpc
related
settlement
operation
in
the
auto
settlement
scenario
that
we
require,
or
that
we
recommend
creating
this
settlement
span
as
a
child
of
the
deliver
span?.
B
B
So
let's
say
we
don't
have
the
span
for
settlement,
but
we
still
have
the
transparent
spans
underneath
the
processing
or
delivery
right
then,
what
else
we
would
need
to
know
you
is
will
be
enough
to
have
an
attribute
that
says:
auto
settlement
was
on
and
then,
as
a
user.
I'm
looking
into
this
and
I
see
okay,
auto
settlement
happened
here.
B
It
was
overall
successful
because
the
overall
span
is
successful
right
and
I
see
some
spans
at
the
end
that
I
can
probably
by
looking
into
this
transparent,
spans,
maybe
say
they're
related
to
settlement,
but
I
have
to
parse,
for
example,
past
to
know
what
kind
of
settlement
and
or
what
was
the
destination
of
this
call,
and
things
like
that.
If
I
configured
everything
properly
right
amir
did
I
get
your
suggestion
right.
C
I
think
that
my
experience
with
their
messaging
instrumentation
showed
me
that
there
was
such
a
wide
variety
and
their
needs,
and
I'm
kind
of
thinking
of
on
the
perspective
of
beckoned
implementer
like
we
get
the
traces
and
we
need
to
automatically
understand
what
happened.
C
If
there
are
issues
about
things
that
we
need
to
to
index
or
expose
to
losers
and
then
like
what,
if
I
have
a
trace
with
no
settlements,
is
there
a
still
way
that
I
can
write
some
logic
that
will
cover
most
of
the
cases
that
will
help
me
figure
out
what
happened
like
if
the
message
is
settled
or
not?
So
because
a
lot
of
people
they?
C
C
They
sometimes
they
don't
like
it,
and
they
want
to
to
leave
spence
that
they
don't
give
a
lot
of
value
to
them
and
then
having
an
attribute
under
the
level
span
could
be
a
great
solution
in
my
opinion,
like
to
describe
it
as
an
alternative
to
creating
the
settlement
in
a
specific
span
or
an
event.
C
As
long
as
it's
specified
in
the
specification,
and
we
can
write
a
general
logic
to
handle
all
cases
in
backlines.
B
Yeah,
it
makes
sense.
One
thought
I
had
that
in
theory,
adding
to
spam
is
a
non-breaking
change
rate
that
we
can
always
add
and
if
we
don't
have
to
be
like
we,
if
we
don't
require
the
span
for
now,
but
we
will
describe
it,
we
can
say:
okay,
it's
it's
optional
for
now.
Here
is
a
semantics.
You
should
follow
if
you
don't
follow.
B
The
semantics
here
is
an
attribute
that
you
can
add-
or
maybe
don't
add,
an
attribute
at
all,
because
by
looking
into
the
end
of
the
call,
you
will
see
plans
or
something
that
will
tell
you
it
happened
and
then,
as
the
case
can
optionally
on
board
into
it
and
in
after
we
won,
we
can
see
the
feedback,
maybe
get
some
inputs
and
say:
okay,
it's
actually
required
in
this
cases
and
that
cases.
B
C
Understand
the
settlement
result
in
all
cases,
that's
the
most
important
thing,
for
example,
in
the
low
settlement
in
rabbit,
you
can
configure
no
settlement,
so
it's
like
the
broker
just
fire
and
forgets
it,
and
then
there
will
be
no
settlement
because
there
is
no
settlement.
I
can
send
this
on
the
tcp
socket
and
the
client
receives
it
and
passes
it,
but
no
settlement
takes
place
and
I
imagine
like
an
attribute
on
the
the
level
spent
saying
no
settlement
war
settlement
equals
no
something.
B
Yeah
my
only
worry
about
the
attribute
is
that
if
we
in
v2
will
have
a
stronger
requirements
around
settlement
span,
then
removing
the
attribute
would
be
a
breaking
change.
So
if
we
don't
need
to
introduce
it
at
all,
it
will
solve
this
problem
as
well.
D
But
we're
talking
about
the
delivery
span,
but
is
it
we
also
is
it?
Is
it
implicit
that
this
is
also
the
same
for
the
receive
span
for
the
cause
for
the
case
of
of
push
based
or
because
for
the
delivery
case,
is
a
pull
push
base
right
so,
but
for
for
the
receive
case
where,
where
the
user
requests
the
message,
then
we
cannot
make
the
we
cannot
make
the
the
settlement
span
sibling
right
of
the
receipt.
A
Yeah,
I
think,
for
receive,
there's
also
no
auto
settlement.
I
think
it's
not
really
really
an
a
problem
for
the
for
the
pool
based
scenarios,
so
I
think,
with
the
receive
span,
it
doesn't
make
sense
to
have
all
the
settlement
there,
because
the
basically
a
separate
separate
operation,
but
I
also
like
what
luke
miller
proposed
and
trust
in
a
rephrase
is
that
we,
just
basically
we
don't
really
know
or
the
sdk
cases
yet
and
what
they're
gonna
do.
So.
A
We
just
provide
like
a
limited
specification
if
we
say
okay,
that
is
the
that's
how
the
settlement
span
should
look.
If
you
want
to
create
a
span.
There
is
maybe
an
alternative
way
just
to
to
signify
settlement
by
having
those
attributes
which
is
might
be
probably
used
for
kind
of
just
local
settlement,
so
those
door.
B
Yeah
me
too,
I
just
just
want
to
make
one
comment
about
the
attributes.
If
we
don't
do
span,
I
believe
we
should
probably
talk
about
event,
because
I
think
we
still
want
to
timestamp
and
we
still
want
maybe
more
than
one
attribute
like
we
would
want
to
say
that
for
some
systems
so
yeah
there
are
like
two
different
ways
to
settle.
A
C
I
made
few
sketches
for
linux
and
we
talked
about
it
on
the
last
few
minutes
last
week,
but
following
the
the
sig
meeting,
where
bogdan
was
in
bogdan.
That
then
for
some
reasons
he
doesn't
like
links
and
he
doesn't
want
a
lot
of
links
in
the
places.
I
don't
share
this
vision.
C
To
be
honest,
I
don't
understand
why
we
want
to
avoid
links,
but
here
I
described
like
a
few
scenarios
well
because
in
some
sometimes
the
sdk
can
guarantee
that
the
settlement
span
will
be
the
child
of
the
liver
span,
who
will
have
a
context
in
the
parent
child
relationships,
but
sometimes
it's
not
possible.
It's
totally
possible
that
the
the
settlement
span
will
be
on
a
different
race.
C
Maybe
there
will
be
a
few
spends
between
the
delivery
and
the
settlement,
and
then
it
makes
life
very
hard
for
beckoned
systems
because
they
have
to
traverse
the
the
trace
to
to
to
have
some
heuristics
on
understanding.
What
happened
like
something
was
settled.
What
was
settled
in
which
context
I
tried
to
do
it
in
the
current
semantic
conventions,
and
it's
really
hard,
and
I
think
links
can
make
it
very
easy,
and
I
want
to
hear
your
opinion.
C
A
Yeah,
I
mean
I
mean
the
the
relationships
here
for
delivery
makes
sense,
but
I
think
they
make
even
more
sense
for
receive
because
in
with
receive
spends,
you
don't
have
much
weight
to
kind
of
even
have
the
settlement
to
be
a
descendant
of
receive
because
receive.
Basically
it's
just
this
a
pull
operation
that
where
basically
the
receive
span,
ends
before
you
get
to
any
processing.
A
So
I
think
for
for
delivery.
That
kind
of
linking
having
some
way
of
linking
it
together
that
is,
can
possibly
be
achieved
by
parent-child
relationships,
but
for
for
receive
it
cannot
so
for
receive.
I
think
if
we
want
to
have
this
correlation,
we
need
something
like
like
links
to
achieve
that,
and
I
mean
I
I'm
I
like
using
inks
too,
because
it
makes
modeling
very
easy,
but
I
saw
that
yeah
once
you
go
out
in
the
community
and
kind
of
talk
about
that.
A
There
is
some
resistance,
so
we
probably
have
to
yeah,
be
patient
and
and
fight
through
that.
But
I
also
think
that
for
us
here,
we
need
to
use
links
in
many
scenarios
to
just
model
what
we
want
to
model.
C
But
my
point
of
view
is
that
if
we
don't
specify
them
at
all,
then
people
will
just
come
up
with
their
own
conventions
for
links
like
for
the
attributes
and
when
to
use
them
and
how,
but
so
so,
if
we
don't
specify
it
all,
we'll
just
end
up
with
a
zoo
of
options
and
if
we
just
specify
it
as
optional
thing,
then
we'll
still
have
a
consistency.
C
A
Yes,
look,
look
nilla,
I
I
wonder
for
for
measure
sdks
or
for
for
for
for
event
hubs.
This
settlement
span
that
is
created
there.
Are
you
using
games
to
link
you
to
other
spans
already
now
or
how
are
those
kind
of
correlated.
B
For
event
hub,
we
cannot
create
links
because
it's
checkpoint
based
settlement
and
we
can't
link,
but
if
it's
a,
if
it
happens
in
the
processing
group,
then
it's
a
child
for
a
service
bus.
I
don't
think
we
create
links,
I'm
not
even
sure
instrument
settlement
called
no
languages,
so
it
gets
blurry
there.
But
if,
if
I
have
done
it
now,
it
will
be
processed,
it
will
be
child
of
settlement
and
it
would
have
a
link
to
the
messages
links
to
the
messages
being
sent.
C
A
In
in
my
experience
or
in
discussions,
I
had
I
see
that
some
people
like
broke
down
the
seedlings
as
a
as
a
special
case
for
as
a
special
case
of
current
parent-child
relationships,
so
that,
basically,
I
think
at
the
start
of
all
this
open
tracing
in
open
senses,
people
trusted
parent-child
relationship
and
trips,
and
then
it's
okay,
there's
some
cases
where
we
can,
where
parent-child
relationships
are
not
enough,
like
some
scatter
gather
scenarios
or
batch
processing
scenarios
and
very
usually
would
use
parents
tried
relationships,
but
you
couldn't
because
of
kind
of
the
want
to
end
restrictions
that
you
have
with
the
parent-child
relationships,
and
for
that
basically
they
said.
A
Okay
for
these
scenarios,
we
can
then
use
links
as
a
special
case
of
parent-child
relationships
and
that's
still
how
many
people
see
or
how
some
people
still
see
links.
They
see
it
as
a
special
case
of
parent-child
relationship
and
here,
for
example,
with
the
settlement
and
create
they
don't
see
this
kind
of
parent-child
relationship
and
they
say:
okay
yeah,
then
we
actually
we
should
not.
We
should
not
use
links
here.
D
But
I
think
from
from
the
last
meeting
that
we
had
where
we
discussed
this
with
bogdan,
I
think
he
like,
I
got
the
feeling
that
he
understood
the
need
that
we
had
and
I
think
he
even
agreed
with
with
most
of
the
case.
I
think
it
was
just
the
last
the
last
drawing
I
saw
the
the
last
diagram
from
the
otep
that
got
him
a
little
bit
confused
or
he
didn't
agree
too
much.
D
But
if
I
remember
correctly,
I
think
he
I
think
he
understood
that
we
have
the
real
needed,
there's
no
real
good
way
to
solve
it.
So
I
think
it
was
only
the
last
example
that
got
him
a
bit
confused,
but
I
think
I
think
we
had
some
some
agreement
and
some
advancement
there
on
that
building.
A
He's
definitely
he's
soft
softening
up,
but
that's
what
it
will
need
some
time
and
some
resistance
from
our
side
to
kind
of
convince
people.
There
was
also
just
on
the
outside,
seeing
some
other
discussions
related
to
http,
where
they
wanted
to
model
retries
and
also
use
links
to
to
kind
of
link.
Those
three
tries
together
and
actually
that
proposal
now
is
kind
of
yeah
postponed,
also
because
of
pushback
from
bogdan
because
yeah
he
didn't
kind
of
the
parent
child
relationship.
A
Here
I
mean,
in
our
cases,
in
all
the
examples
that
we
showed
to
block
down
for
this,
basically
linking
producers
and
consumers
together,
you
can
argue
that
there
is
a
parent
child
relationship
there,
because
there's
a
producer
there's
the
consumer.
Here,
the
message
is
created
here:
it's
basically
processed,
that
is
a
special
case,
more
or
less
of
parent-child
relationship.
A
So
I
think
that
this
that
is,
okay
for
him
and
just
in
the
last
example
that
we
looked
at
it's
just
here.
That
was
the
special
one
where
he
actually
was
required
to
adding
links
after
spank
creation
and
that's
where
he
was
pushing
back.
But
I
I
just
think
in
the
long
run,
this
links
will
be
used
more
freely.
A
Definitely
it's
just
a
matter
of
here
of
people
out
there
actually
starting
to
use
links
and
yeah
people
getting
used
to
it.
D
But
I
I
think
if
we
have
clear,
clear
directions
in
the
spec
when
to
use
them
how
to
use
them,
then
we
should
be
safe,
and
I
mean
people
can
still
do
wrong
things
anyway
anywhere.
So.
A
Yeah
I
mean
the
the
the
push
back
there.
I
kind
of
it's
often
pretty
exhausting,
but
I
kind
of
understand,
because
it's
there's
a
stable
tracing
spec
out
there
and
that
basically
would
be
an
addition
or
to
this
stable
tracing
spec.
So
people
yeah
really
want
to
make
sure
that
that,
yes,
that
really
makes
sense
before
all
the
sdks
kind
of
start
implementing.
I
just.
D
I
just
have
a
quick
question,
maybe
it's
stupid,
but
for
the
settlement
of
the
diagram
that
we're
looking
it's
it's
clear
that
we
can
add
links
to
the
create
because
we
have
the
message.
But
but
how
would
we
add
a
link
to
the
delivery
span,
because
I
mean
how?
How
would
we,
how
would
we
get
the
the
the
delivery
span?
Is
it
just
squaring
the
active
span
or
or.
C
A
You
would
need
some
additional
way
of
context
propagation,
because
then
you
would
in
some
way
or
the
other
kind
of
give
this
delivery
context
here
to
the
set
exactly
yeah.
C
You
can
just
add
attributes
to
to
the
message.
Okay,
let's
see
hey
the
delivery
spans
associated
with
this
message.
Is
this
one.
C
Certainly,
to
have
access
to
this
context.
D
Okay,
so
you
just
as
the
you
just
use
the
message
as
a
mean
of
moving
down:
okay,
okay,
gotcha,
very
common
in
javascript
and
python,
and
movie
okay,
gotcha
thanks
for
clarifying.
E
Sorry
yeah,
I
was
just
gonna
say
that
some
ap
apis
don't
allow
that
like
a
message
they
have.
They
have
the
content
of
sort
of
incoming
messages
and
outgoing
messages.
If
you
create
a
message
to
send
it's
a
it's
a
mutable
object
when
you
receive
it,
it's
an
incoming
message,
it's
immutable
and
so
relying
on
being
able
to
use
a
message
to
store
a
state.
E
E
B
Like
the
message
as
an
sdk
or
owner,
I
can
change
the
message
type
and
I
can
add
stuff
there
in
theory,
but
it
might
be
very
inefficient.
It
might
require
a
lot
of
changes
and
I'm
not
sure
I
will
get
a
lot
of
support
without
a
lot
of
business
justification
right
for
this
change.
So
I
think
it's
useful
and
we
should
try,
but
we
can't
require
a
lot.
C
B
B
C
A
A
Okay,
we
are
over
time
already.
I
think
we
make
good
progress.
I
will
try
to
write
up
in
the
old
tap
what
we
came
to
hear
regarding
the
spans
spans
and
events,
and
maybe
next
time
we
can
continue
talking
about
which
links
you're
going
to
require
or
recommend
for
settlement,
and
then
maybe
have
a
quick
discussion
about.
Also
the
if
we
want
us
if
we
want
to
put
anything
about
process
spends
into
the
old
tap.
I
think
that
was
another
open
point
that
we
need
to
discuss
before
we
can
go
over
to
attributes.