►
From YouTube: 2022-10-13 meeting
Description
Instrumentation: Messaging
A
C
A
A
C
C
Yeah
I
try
to
prepare
some
things
for
this
meeting
as
a
shroud
that
he
does
not
have
time
for
this
week
and
if
you
have
anything
you
want
to
add
to
the
trend
or
just
edit
on
the
bottom
there
there
are
some
on
top
here.
Some
things
I
was
working
on,
so
so
I
put
it
there,
because
that's
where
I
can
like
speak
most
to
the
first
one
is
yeah.
We
decided
we
want
to
retire
this
big
old
tap
one
92.
C
And
that's
why
I
split
out
we
already
split
out
context,
propagation
and
I,
also
split
out
the
span
structure
or
the
trace
structure
PR,
and
we
we
have
this
one
open
here.
This
large
one
like
more
than
200
commands
lots
of
discussions
in
in
there
which
are
useful
to
have,
but
we
don't
want
to
continue
working
on
this
one.
C
So
as
we
continue
here,
I
just
wanted
to
get
the
people's
opinion
here
on
how
to
pass
how
to
best
continue.
I
think
one
one
option
would
be
for
me
the
preferred
one
just
to
completely
close
this
PR
and
continue
discussions
in
other
pairs.
C
We
already
have
the
context
propagation
stuff.
That's
that's!
That's!
That's
basically
done
that's
working
with
structure,
we
have
a
dedicated
PR
and
also
for
the
attributes.
We
have
this
like
a
draft
PR
on
this
back
side,
but
then
the
only
thing
I'm
not
sure,
is
if
that
attributes,
PR
kind
of
captures
everything
what
we
put
here
in
terms
of
attributes
because
remember
we
had
some
discussions
about
the
app
having
source
and
destination
attributes
and
I.
Think
we
put
something
in
here
and
I
think
that
is
not
covered
in
the
spec
PR.
C
Yet
so
just
a
I
just
wanted
to
like
know
from
your
side
whether
you
are
with
that
in
mind,
you're
fine,
with
closing
this
PR
here
completely
and
continue
basically
discussions
in
the
two
other
parts
that
you
have:
the
trade
structure
PR
and
the
attributes
PR
in
the
spec.
A
Well,
I
guess:
the
other
player
is
so
big
that,
even
if
we
are
losing
some
small
pieces,
I
have
to
I
think
we
have
to
assume
that
risk,
because
it's
the
other
Pi
is
so
big
that
it's
unmanageable.
D
Yeah
I
just
want
to
point
out
that
the
the
existing
attributes-
PR
that's
listed
in
the
agenda,
was
only
meant
to
kind
of
change.
The
structure
of,
what's
in
the
existing
experimental,
attribute,
expects
attributes
and
and
wasn't
meant
to
cover
things
that
we
were
covering
in
in
Otep
192.
So
I
don't
think
we
have
that
I,
don't
think
we
have
attributes
quite
covered
off
yet,
but
I
think
it's
fine
to
still
split
it
out
and
it
I
just
don't
think
we
have
the
attributes
part
covered
yet
under
another
PR.
C
Attributes
or
do
you
have
any
idea
for
covering,
like
the
the
missing
attribute
Parts
as
to
any
set,
so
that
should
be?
Do
you
think
we
should
open
like
a
a
a
draft,
spec
PR.
B
C
B
Yeah
sorry
yeah,
our
initial
thinking
was
that
maybe
we
will
do
a
small
incremental
changes
and
this
TR
was
up
and
to
address
just
one
thing
part
of
it.
Then
we
kind
of
realized
that
that
it
goes
against
the
new
process
and
we
would
rather
need
Chocolate
News,
remember,
yeah,
I,
guess
the
the
concern
with
it
was
that
we
we
potentially
introduced
multiple
breaking
changes
at
different
times
and
we
wanted
to
bundle
them
together.
B
So
we
can
I
think
what
prevents
me
from
working
keep
working
on
this
PR
is
I.
Don't
really
understand
what
our
strategy
is
now
so
should
you
try
to
bundle
all
attributes
there,
but
we
didn't
like
agreed
to
all
of
these
attributes
yet
or
should
we
just
do
what
what's
in
there
and
avoid
like
putting
everything
in?
B
C
Yes,
that
we
agree
because
that's
that's,
that's
the
point
that
I
want
to
deeply
up
to
date
because
we
have
like
quite
We,
have
basically
three
pieces
in
flight
and
yeah.
There's
at
least
there's
lots
of
overlap
here.
So
we
should
kind
of
yeah
get
like
a
key
or
tier
directly
for
us
how
to
follow
up
with
that.
A
So
should
we
start
a
new
umbrella
PR
that
says:
okay,
we
have.
A
B
I
actually
have
a
suggestion
that
before
we
really
open
PRS
in
this
Factory
ball,
we
agreed.
We
agree
with
Beyond
ourselves
in
something
because
it's
very
hard
to
open
this
pier.
It
gets
a
lot
of
comments
from
the
community
and
within
ourselves,
and
it's
just
this.
This
iteration
becomes
harder.
So
maybe
we
can
start
creating
this
spec
as
we
like
it.
We
cannot
like
stand
behind
it
and
then
we
bring
something
we
have
consensus
on
to
the
community.
C
Yeah
I
definitely
I
definitely
agree.
I.
Think
the
first
step
for
us
is
just
to
come
up
to
a
consensus
in
this
group
and
then
based
on
that
the
kind
of
yeah
we
we
go
to
the
like
wider
community
and
try
to
get
this
into
the
stack
s.
C
C
Yes,
so
the
question
is
whether
we
kind
of
still
work
on
I
think
it
was
the
initial
idea
that
we
basically
stabilized
the
existing
spec
and
do
changes
to
this
one,
and
then
that
already
fat
year
was
just
that
we
leave
it
as
it
is,
and
we
just
come
up
with
the
V2
version
of
the
spec
that
lives
in
parallel.
B
Realistically,
we
are
creating
a
new
major
version
of
the
stock,
because
we
are
changing
stance
structure.
We
are
changing
almost
every
attribute
and
I,
don't
think
we
like,
we
can't
try
to
evolve
it
and
we
probably
will
be
successful.
It's
just
every
step
will
will
have
to
think
about
all
of
this
breaking
changes.
A
Okay,
so
should
we
start
strategy
document
somewhere
where
we
basically
agree
on
a
common
strategy
to
to
move
this
forward.
C
I
I
think
the
problem
here
is
that
there'll
be
alone
in
this
group.
I
think
we
don't
have
all
the
power
to
do
100
decide
which
strategy
we
should
follow
here,
because
if
we
put
up
like
an
additional
basically
version
that
it's
in
parallel
of
the
semantic
conventions,
I
think
we
need
some.
We
need
some
blessing
for
this
from
the
technical
committee.
A
That's
that's
why
having
a
strategy
document
would
be
helpful
because
we
could
agree
on
a
strategy.
So
basically
saying
this
is
the
scope
of
the
work
that
we
want
to
do.
We
want
to
change
this
and
this
and
that-
and
we
have
these
all
tabs-
that
describe
specific
specifics
on
the
or
how
we
want
to
do
that,
and
we
don't
need
to
have
the
your
tabs
ready.
We
just
need
to
to
Define
their
scope,
but
if
we
go
to
the
spec
meeting
with
something
tangible,
I
think
I
think
it
can
be
discussed.
B
That
that
idea
of
the
creating
spec
V2
a
parallel
one
I
think
it
came
from
Christian
from
Oberon
and
he
is
approval
and
stacks
on
tracing
and
I.
Guess
if
we
come
to
the
technical
committee
and
say
this
is
what
we
think
and
if
it's
the
same,
what
what
if
Christian
agrees,
I
think
this
puts
enough
weight
for
them.
B
I
cannot
speak
on
behalf
of
them,
but
my
impression
they
will
just
plot
us
together
with
Christians,
decide
because
he
Christian
is
a
program.
They
trust
him
in
the
states
but
and
I
I
think
we
can
create
a
documents,
but
all
the
people
who
will
read
it
will
be
us.
C
Well,
I
mean
it's
the
next
step
here.
I
will
I
will
discuss
that
with
joao
and
maybe
he's
willing
kind
of
to
bring
that
up
in
a
PC
meeting,
because
he
he
has
like
a
collections
there.
He
sometimes
attends
to
see
meetings
and
also
he
he
was
leading
some
context.
Propagation
related
discussions
there
and
he
knows
the
Christian
very
well
to
work.
The
work
I
think
in
the
same
company,
so
I
will
ask
Frau
whether
he,
whether
he's
willing
to
print
it
up
what.
A
Well,
the
reason
I
mentioned
the
documents.
It
doesn't
need
to
be
a
Bible,
it's
like
for
paragraph
or
two
very
clearly,
because.
A
We
want
to
have
a
clear
strategy
before
we
ask
if
that
is
right
or
wrong,
because,
right
now
we
are
going
to
say:
oh,
we
have
these
two
options.
Do
we
evolve
that
or
do
we
create
a
V2
and
I?
Imagine
people
also,
but
what
needs
to
be
evolved,
and
why
do
you
need
the
V2
and
the
justification
for
these
questions
should
be
well
clearly
enough,
both
for
us
mainly
for
us
to
explain
and
for
the
people
to
understand.
So
it's
kind
of
a
justification
for
all
this
work.
A
C
I
mean
I
can
do
that,
and
that
might
anyway
be
good
when
handing
this
over
to
show
I
can
just
write
a
paragraph
summarizing
those
two
options:
I
mean
if,
if
Time
We
can
brainstorm
here
a
bit
about
pros
and
cons
that
you
see
and
also
because
look
middle,
you
asked
about
the
people's
opinions
here
and
I'm
a
bit
I
mean
I,
don't
have
two
strong
opinions,
I
think
in
the
long
run,
it's
just
I.
C
C
So
in
the
long
run,
that
is
kind
of
for
me,
like
a
goal
and
whatever
whatever
like
way
brings,
is
faster
there
I'm
fine
with
that
in
the
on
the
short
run,
I
see
some
some
confusion
that
might
be
caused
by
actually
having
two
unstable
versions
or
two
experimental
versions
of
messaging
semantic
conventions
being
present.
C
C
So
maybe
it's
good
well
Bruno
suggest
to
you
that
if
we
come
up
with
this
proposal
for
having
a
V2
that
we
also
have
a
key
roadmap
for
for
how
we
gonna
how
we
gonna,
how
we
gonna
deal
with
like
two
experimental
semantic
conversions
being
there
and
what
to
expect.
How
long
do
we
expect
the
two
to
be
there?
C
On
the
other
hand,
I
see
the
benefit
because
yeah
I
think,
if
you
just
put
up
something
completely
new,
there's
no
package
that
you
carry
around
and
when
it
conflicts
with
reborn.
Who
cares
so
it
kind
of
it
might
be
easier
for
us
to
get
just
like
big
changes
in
there
and
there
might
be
less
pushback
like
in
in
that
regard,
but
any
other
other
question,
as
I
said
before,
is
yeah.
There's
I
think
there's
no
precedent
of
retiring
semantic
conventions.
C
A
There
is
a
risk
that
the
only
allow
us
to
retire
old
properties
once
they
once
we
change
major
version
aversion
on
the
spec.
B
I
think
the
there
is
a
middle
ground
here,
so
the
current
spec
or
it
works
for
a
single
message
scenario
quite
well,
except
maybe
attribute
names.
We
wanted
them
to
be
different
right
and
in
this
sense,
for
a
single
message,
this
pack
can
evolve
and
V2
is
basically
the
batching
case
and
for
batching
case
it's
the
whole
news
fact
that
covers
completely
different
cases.
B
B
What
would
be
the
same
between
batching
and
the
single
message
case,
but
the
span
structure
is
completely
different
and
everything
else
is
different
and
now
the
controversial
things
about
links
and
events
or
the
you
know,
many
other
things
are
stained
and
the
this
other
document
that
doesn't
exist
yet.
A
So
basically,
we
guide
the
current
experimental
spec
to
be
as
complaint
as
possible
as
the
V2
that
we
envision.
We
focus
it
on
just
the
the
single
message
scenario
and
we
align
all
the
conventions
to
Target
things
that
we
are
going
to
use
on
V2
and
when
we
introduce
V2,
we
add
the
scenarios
for
batching
and
everything
will
work
together.
A
B
A
Come
yes,
yeah
and
I
think
if
we
do
that,
we
can
even
avoid
calling
it
V2,
because
people
kind
of
are
a
bit
jumpy
with
jumpy
with
versions
and
if
we
call
it
just
the
batching
scenario,
which
is
an
extension
of
what
we
have
now
effectively
I,
think
it's
easier
to
sell.
C
Mean
I
I
like
the
two
in
theory,
but
when
I
start
to
think
a
bit
about
it,
I
think
there
is
some
with
our
current
proposals.
There
are
some
very
fundamental
things
that
we
want
to
do
different.
Actually,
even
when
I
just
think
about
the
singer
like
message,
scenarios
I
mean
we're.
Definitely
in
all
those
two
scenarios
we
want
to
have
attribute
names
to
be
like
consistent.
C
So
that's
something
we
would
need
to
change.
Even
in
the
existing
single
message,
semantic
convention
messaging
semantic
conventions.
You
would
need
to
change
the
attribute
names
according
to
our
proposal
and
if
and
also
for
fundamental
questions
like
the
span
structure,
I
mean
it's
SV
Envision
it.
We
don't
want
to
have
like
parent
trial
relationships
between
producers
and
consumers,
even
in
the
single
messaging
scenario,
but
it's
the,
but
this
is
kind
of
more
or
less
the
preferred
way
put
forth
now
into
existing
semantic
conventions.
C
So
I
think,
even
when,
when
when
we
go,
this
approach,
which
I
mean
might
be
a
good
middle
ground
between
those
two
but
I
think
they
still
don't
get
around
in
just
making
yeah
kind
of
breaking
changes
to
the
to
this
envisioned
single
messaging
semantic
conventions,
but
yeah
I'm,
not
sure.
If
that
is
even
a
bad
thing,
I
mean
it's.
It
kind
of
the
changes
will
definitely
be
more
contained
into
solution.
A
So
if
we
could
write
something
short
that
says
basically
what
we
discussed
now
here,
that
would
be
the
proposal
that
we
would
present
and
see
what
they
say.
B
I
think,
even
for
the
span
structure,
I
I
think
we
discussed
a
little
the
different
things
regarding
the
productive,
consumer
and
parent-child
relationship
first
time,
but
regardless
of
what
they
pick
the
things
we
can
change
the
structure,
an
existing
spec
from
my
experience
very
few
people
care
about
spend
structure
when
they
read
this
full
requests
at
all.
So
I
think
it's
it's
fine!
It's
just
that
we
can
evolve
this
currents
back
to
to
be
compatible
with
what
we
think
is
right
and
what
should
they
tell
you.
B
Or
yes,
we
can
evolve
current
stack
to
be
what
you
think
is
right
for
the
single
message
case
and
it
will
be
not
a
huge
change
from
the
current
stock.
B
If
you
want
I
can
write
down
this
in
I,
don't
know
half
page
or
other
page
or
something,
and
we
can
share
it
and
please
classification
and
ask
him
to
bring
it
up.
Foreign.
C
Basically,
the
middle
wave,
we
evolved
existing
semantic
conventions
for
the
single
measured
message
case,
but
we
put
up
like
a
new
document
for
the
batching
scenarios.
We
basically
have
the
we
do
this
here
for
the
single
message
case
and
we
do
this
co4
back
in
case.
So
we
have
kind
of.
C
C
Okay,
so
I
think
next
steps
are,
are
here,
just
you're
putting
this
into
some
like
short
document
and
then
maybe
asking
how
to
to
to
push
this
to
the
auto
present
this
at
the
TC
level
and
get
feedback
from
there.
B
So
I
can
also
try
to
join.
Let
us
make
me
confused
to
end
each
house
exactly
awesome.
A
C
Yeah
I
think
the
DC
meeting
is
not
for
DC
members.
Only.
You
can
kind
of
present
proposals
there
and
basically
because
directly
from
the
DC
members
and
remember
shout
did
that
for
like
the
context
propagation
stuff,
because
there
was
some
like
some
pushback
anti-present
it
there
and
that
kind
of
unblocked
us
so
and
he
I
think,
for
our
also
did
that
for
some
otlp
extensions
that
he
was
working
on,
he
kind
of
worked
directly
with
like
TC
people
and
that
called
things
to
kind
of
move
faster.
C
And
then
what
we
chose
to
to
be
trust
would
yeah
summarize
that
so
I
can
I
can
put
up
a
Google
doc
and
start
it.
I
will
share
that
in
the
channel
and
then
people
can
be
in
and
they'll.
Maybe
we
end
up
with.
Hopefully
we
end
up
with
something
that
Danielle
we
can
hand
over
to
Xiao
it's
great
to
assign
work.
Talking
he's
not
here
today.
So
let's
see
how
lucky
we
arrested.
C
Okay,
so
that
sounds
good
I
think
we
got
some
clarifications
and
next
steps
here
for
our
overall
strategy
I'm
still
not
completely
sure
what
to
do
with
192.,
but
I
I
I.
Think
I
will
just
close
this
PR,
because
the
contents
and
the
discussions
will
be
still
available
anyway.
C
We
can
reopen
it
if
needed
and
I
think
what
we
should
prevent
is.
You
are
just
having
now
more
discussions
and
having
more
people
commenting
on
this
PR,
because
it's
just
it's
kind
of
lost.
B
C
Okay,
I
have
so.
C
I
have
some
I've
had
some
feedback
on
this
old
tab
here
on
the
tray
structural
tab,
some
good
feedback
from
Bruno,
also
from
Paolo,
and
one
thing
I
wanted
to
bring
up
here
and
ask
you.
People
is
about
to
think
that
Paulo
brought
up
about
producer
settlement,
so
he
talked
to
be
in
our
in
the
current.
Let's
open
it
in
the
current
the
intercurrent
draft.
C
We
talk
about
like
consumer
settlement,
so
we
have
settlement
scenarios
on
the
consumer
side
that
we
cover,
but
Polo
brings
up
the
the
scenario
of
settlement
on
the
producer
side,
so
settlement
scenarios
on
the
producer
side
and
Aya
Bruno.
You
were
involved
too
in
discussions
yeah
and
I
I
was
wondering
how
do
those
settlement
scenarios
on
producer
site
look
like
asked
for
some
pointers
and
examples,
and
then
I
have
I
didn't
have
time
to
look
into
that.
C
It
did
that
yet,
but
Paulo
here
brought
some
exam
black
from
amkp
side,
where
you
can
like
have
some
saddle
flag.
That
then
causes
you
to
wait
for
some
answer
from
the
broker
intermediary
in
that
case,
but
I
think
this
just
covers.
Basically,
this
is
a
different
kind
of
settlement.
It's
a
settlement
on
a
transport
level
as
far
as
you
understand,
because
it
just
says
that
the
broker
kind
of
received
your
message
and
processes
it
further.
So
that
is
not
a
settlement
as
a
kind
of
a
that's
a
different
cut.
C
C
But
I
just
wanted
to
ask
ask
people
here,
maybe
most
yeah,
Bruno
Miller
and
two
and
two
about,
like
your
your
take
on
like
the
settlement
scenarios
on
producer
side,
whether
it's
something
that
that
that
comes
up
a
lot,
that
you
see
a
lot,
whether
it's
something
you
think
we
should
cover
in
those
semantic
conventions
or
whether
this
is
something
that
is
kind
of
a
more
esoteric
or
or
special
thing.
D
I
think,
knowing
like
the
outcome
of
the
message
send,
is
important:
I
guess
the
question
is:
would
the
send
or
maybe
publish
band
but
I
think
we
know
what
I
mean
either
way
the
the
let's
say
publish
span?
Would
it
end
after
the
settlement
like?
Would
it
start
when
you
send
and
then
end
when
it's
settled,
and
then
the
outcome
of
the
settlement
is
embedded
into
the
publish
span?
D
I
think
that
maybe
is
ideal
and
you're
measuring
that
you
know
how
long
it
it
took
for
that
to
be
to
happen.
But
but
then
you
have
to
consider
scenarios
too,
where
you
know
settlement
maybe
takes
a
really
long
time.
There's
always
Corner
cases
with
these
things
right,
where
maybe
you
get
disconnected
and
there's
a
you
know
a
redundancy
failover
to
their
machine,
and
maybe
it
doesn't
come
up
right
away
and
then
you
finally
connect
in
you
finally
get
a
settlement.
D
Is
it
okay
to
leave
the
span
running
or
would
you
rather
you
know,
end
your
publish
span
after
some
time
out
and
indicate
that
it
timed
out
and
then
and
then
the
question
is:
how
do
you
handle
sort
of
an
asynchronous
settlement
later
so
I
think,
ideally
it's
it's
all
that
information
is
in
the
publish
span,
but
there's
probably
Corner
cases
where
it
can't
be
or
may
not.
Maybe
we
can't
do
it.
C
Yes,
that
was
my
initial
understanding
too,
that
we
have
this
published
span
and
this
published
span
has
some
kind
of
success:
state
I,
don't
either
the
publishing
fails
or
succeeds,
and
basically
this
is
how
we,
how
we,
how
we
denote
this
this
kind
of
settlement,
but
still
I,
think
we
are
I
I'm
not
going
through
all
of
power
scenarios
yet,
but
I
think
there
is
there's
this
one
scenario
where
settlement
on
the
producer
side
just
means.
C
Okay,
this
message
was
successfully
accepted
by
the
intermediary
and
in
this
case,
as
I
said,
these
two
will
think
that's
the
mqp
scenario,
I
think
there's
other
scenarios
to
bring
software
settlement
actually
means
okay
to
producer
Waits
until
the
this
message
was
processed
by
the
consumer,
and
that
can
and
then
get
some
kind
of
confirmation
about
that.
I
think
that's
what
his
it
seems
to
me.
What
his
JMS
example
is
about,
so
I
think
there
are
two
different
kinds
of
settlement
we
are
talking
here:
I.
D
I,
don't
think
either
amtp
nor
well
ampp
doesn't
have
the
concept
of
a
end
consumer.
It's
it's
just
a
transfer
between
two
peers
with
JMS
I.
Don't
believe,
there's
any
way
to
signal
that
when
the
consumer
is
processed
it
it's
I
did
I
haven't
read
this
comment:
I
apologize,
but.
A
D
D
Talked
about,
we
talked
a
little
bit
about
actually
transactions
a
while
ago
and
and
we,
the
general
consensus,
was
that
although
they
exist,
it's
not
something
that
we
really
want
to
focus
on,
because
we
don't
think
they're
used
widely
enough
to
to
weren't
putting
too
much
effort
into
I,
agree
and.
C
D
Yeah
and
yeah
I
think
he's
talking
about
synchronous
versus
asynchronous
and
if
it's
asynchronous
the
you
know,
in
order
to
end
the
span,
when
you
get
the
asynchronous
acknowledgment,
it
means
kind
of
keeping
that
span
context
or
whatever
around
until
you
get
the
asynchronous
acknowledgment,
which
I
I
assume
is
okay,.
C
Yes
or
or
you'll
just
have
an
additional
like
completion
span
here
that
somehow
links
to
your
or
parents
to
your
public
spend
that.
D
Would
be
yeah
I
guess,
that's
the
question:
do
we
want
separate
spans
for
that
or
or
not
like?
If
you
have
separate
spans,
it's
you're
getting
very
you're
getting
into
sort
of
almost
zero
duration
spans.
D
I,
don't
believe
that
asynchronous
acknowledgments
is
an
edge
case.
It's
very
in
at
least
in
this
the
message,
my
messaging
experience
or
the
kind
of
messaging
I've
been
involved
in
it's
very,
very
common.
It's
the
most
common,
because
any
high
performance
messaging
scenario,
typically
you're
streaming
the
messages
and
getting
asynchronous
acknowledgments,
certainly
gmf
one
dot.
Jms
1.0
didn't
have
that
capability,
and
so
what
a
lot
of
with
GMS,
1.
or
1.1
what
they
did
was
they
would
tend
to
start
using
transactions
as
a
way
of
batching.
D
B
D
Usually
both
like
what
you'll
have
is
usually
some
window.
You
know.
Maybe
it's
you
have
a
window
of
100
messages
and
so
you'll
send
up
to
100
messages
without
getting
any
acknowledgment,
let's
say
and
then
as
the
Brokers
getting
them
for
the
intermediaries
getting
them
and
processing
them.
He'll
start
sending
back
acknowledgments,
often
not
with
every
message.
Often
they
might
be
windowed
so
that
maybe
he'll
wait
until
there's.
D
One
third
of
the
window
you
know
is:
is
there
and
then
he'll
send
it
back
for
that
that
whole
one
third
of
a
window,
and
so
what
that
means
is
inside
usually
inside
the
API,
the
API
abstracts
some
of
this
complication,
but
the
API
has
to
keep
track
of
all
100
messages.
D
Let's
say
that
haven't
been
acknowledged
yet
such
that,
if
there's
a
disconnect-
and
he
has
to
reconnect
that
they
can
then
resend
automatically
the
ones
that
haven't
been
acknowledged
yet
and
if
the
the
full
100
message
window
gets
full,
then
an
application
gets
sort
of
a
flow
control.
You
know
gets
flow
controlled
by
the
API
by
the
SDK
one
way
or
another.
B
So
my
sdks
that
we're
covering
PDF
and
the
following
way:
they,
regardless
of
whether
user
dates
for
the
operation
to
complete
or
not
right,
they
they
wait
for
acknowledgment,
and
they
have
so
like
when
the
asynchronous
operation
ends
right,
regardless
of
what
their
user
was
waiting
for
it
to
finish
or
not,
I
know
about
it
right.
B
So,
if
I,
when
I
create
the
published
fan,
it
captures
the
acknowledgment
for
given
batch
or
a
message
so
that
for
me
the
the
the
settlement,
it's
the
transport
level
act
like
if
it's
a
response
from
HTTP
request
right,
it
doesn't
matter
to
the
extent
and
when
I
receive
response,
I
can
complete
the
span
and
I.
Remember
Rosa
made
this
Choice
initially
that
we
instrument
logical
level.
We
don't
instrument
transcript
level.
At
this
point,
we
thought.
B
D
D
Right,
so
what
are
you
saying?
What
are
you
saying
here
is
when
you
send
a
message
with
settled
equals
true.
That
means
you've
decided
ahead
of
time
that
it's
settled,
you
don't
care
if
it
gets
lost
and
there
won't
be
any
further
acknowledgment
from
the
pier
at
all.
If
you
send
a
message
to
settled,
equals
false.
That
means
that
you
do
want
the
the
the
asynchronous
acknowledgment
that
it
has
been
processed
such
that
you,
you
can
provide
guaranteed
it.
D
Yeah
I
think
it
would
be
I
I.
Think
in
the
amp
amqp
case,
where
you're
sending
a
message
was
settled
equals
true,
and
you
know,
there's
no
acknowledgment,
then
you
would
end
your
spam
right
away
and
because
you
know,
there's
nothing
coming
back
and
you
would
probably
indicate
maybe
that
it's
a
it's
not
an
acknowledged
message
or
something
like
that
and
that
settled
equals
false
would
kind
of
fall
into
the
same
category
as
the
you
know.
Jms
asynchronous
acknowledgment.
D
A
I
have
another
type
of
concerns
this.
This
type
of
async
messaging,
as
you
mentioned,
is
used
for
High,
throughput,
stuff
and.
A
D
But
usually
the
window
is
limited
right,
usually
there's
a
a
configured
window
on
a
session
on
a
connection
and
it's
bounded
like
in
my
experience.
250
is
kind
of
the
maximum,
and
so
you
might
be
dealing
with
tens
of
thousands
per
second
but
you're
dealing
with
maybe
hundreds
of
round
trips
within
that
one.
Second
right,
so
there's
never
more
than
a
couple
of
hundred
in
flight
at
one
time.
So,
yes,
you
might
have
to
deal
with
a
couple
hundred
of
them,
but
it's
not
unbounded.
C
D
C
What
you're
designing
here,
it's
a
question
of
what
does
the
user
see?
Does
the
user
kind
of
just
do
the
send
operation
and
then
once
there
is
an
egg
for
all
hundreds
bands
to
send
operation
ends
I
think
then
it's
got.
Then
it's
basically
added
just
one
span.
This
band
is
blocking
until
your
messages
are
sent
successfully
and
then
at
the
end,
I
kind
of
have
this
success.
State
I.
Think
then,
from
the
user
point
of
view,
I
should
just
have
one
span
and
have
a
success
code.
C
Of
course,
there
are
then
other
like
this
async
sand
operation,
where
I,
maybe
I
I,
have
a
async
sand.
A
call
I
I
pass
100
messages
with
this
async
send
call
and
then
at
some
point
later
kind
of
there's
a
callback
that
gets
called
that
gives
me
then
information
about
the
state
of
this
async
sand
and
then
I
actually
think
in
this
case.
C
From
the
user
point
of
view,
it
should
not
be
one
span,
but
there
should
be
two
spans
because
I
have
this
async
scent
that
like
finishes
pretty
quickly
and
then
I
have
this
other
like
callback
operation.
That
might
be
a
separate
span,
because
if
I
kind
of
keep
this
async
scent
kind
of
active,
it's
it's.
It
can
be
very
misleading
from
the
user's
point
of
view,
because
the
span
shouldn't
going
on
when
kind
of
it
actually
already
ended.
A
C
So
yeah
I
will
I
will
look
into
this.
More
I
will
also
ping
I'm
here
for
some
input
there,
because
he
looked
at
lots
of
of
JavaScript
use
cases
that
were
highly
asynchronous,
so
maybe
he
has
he
has
to
take
on
this
as
well.
We
have
some
ideas
about
this.
Okay
I
will
capture
I
will
try
to
capture
our
discussion
in
like
a
comment
here,
and
maybe,
if
you
have
any
opinions
about
this,
you
can
weigh
in
let's
see
well
sure,
Paulo
response.
C
Okay,
there's
nine
minutes
left,
not
Miller.
You
put
this
on
the
trend,
so
I
will,
if
you
think
nine
nine
minutes
are
fine.
I
will
just
hand
over
to
you.
B
B
Okay,
cool,
so
can
you
share
my
screen.
B
Okay,
so
I
wanted
to
bring
the
all
the
attributes
that
we
discussed
and
I
wanted
to
make
it
then
the
specification,
Ripple,
I,
guess
I'll,
put
the
decisions
we're
going
to
make
regarding
the
separate
document
or
the
same
document.
I
will
change
it,
but
I
want
to
First,
explain
how
this
yaml
thing
works
and
because
I'm
I'm
sure
people
are
not
familiar
with
it.
So
there
is
a
a
list
of
yaml
files
for
each
technology
and
open
telemetry
and
I've
added
this
one
I've
added
a
different
name.
B
It's
currently
called
messaging,
so
it's
just
to
separate
things,
and
so
this
yaml
it
defines
attributes,
but
it's
not
good
for
other
things,
but
it's
a
formal
definition
of
the
house.
Pants
should
look
like
so
probably,
okay,
so
anyway,
so
the
attribute
says
we
see
them
for
the
next
version
or
the
system.
So
you,
when
you
read
it
you're
sure
it
is
prefix
and
then
ID.
B
So
there
are
sorry,
some
very
uncontroversial
attributes
that
we
have
at
the
system
it's
operation,
and
this
is
the
operation
we
defined
in
the
or
tap
and
yeah.
So
this
is
the
like.
You
know
so
what
we
have
here
as
well
is
a
requirement
level.
So
we
can
say
this
attribute
is
required.
So
when
you
create
the
messaging
attribute,
you
must
populate
messaging
dot,
operation
and
but
the
members
you
assign
it's
one
of
this
or
you
can
add
a
custom
value.
B
So
since
this
is
a
formal
definition,
every
detail
matters
so
I
want
to
have
this
document.
So
we
we
have
a
very
formal
thing:
okay,
so
the
operation
system,
and
then
there
are
different
groups.
So
this
group
describes
a
span,
but
it's
it's
like
an
abstract
thing:
it's
not
anything
specific,
so
it
just
describes
the
common
attributes.
All
messaging
spans
should
have
and
then
I
I
needed
it
for
some
some
reason.
But
there
is
also
other
group
of
attributes.
B
It's
just
the
way
to
organize
this
and
inherit
from
different
things.
Think
about
it
as
a
type
hierarchy.
B
So
what
we
have
here
we
can
reference
attributes,
so
the
reference
system
and
operation
defined
in
the
previous
thing-
and
we
also
reference
a
generic
attributes
from
all
other
places
from
Network
specification.
So
all
of
this
are
referenced
attributes
and
then
the
interesting
thing
comes,
the
batch
size
right.
We
decided
to
have
a
messaging
batch
size
attribute
that
describes
the
number
of
messages
sent
received
a
processed
and
it's
an
interesting
question.
B
What
should
we
do
in
a
single
case
because
we
we
can
get
0
or
1
right
if
we
try
to
receive
but
receive
nothing?
It's
still
useful
to
know
whether
we
should
what
should
we
put
there.
Maybe
we
need
a
different
name
for
a
single
case
and
now
Samir
had
some
other
reasons
for
it
for
the
back
end
convenience.
B
So
this
I
think
this.
This
one
should
come
as
the
to-do
item
and
basically
this
there
is
more
here.
This
defines
like
this.
This
thing
defines
the
Pan,
but
to
also
have
message
specific
attributes
and
they
are
listed
here.
We
should
probably
grow
this
list
further
and
improve
the
descriptions
here,
but
then
we
can
now
go
and
Define
some
specific
spans.
So,
for
example,
this
is
publish
and
create
spend
for
a
single
message
case
so
like
when
we
create
when
we
publish
a
span.
B
Sorry,
when
we
publish
a
message,
we
had
two
choices.
We
can
create
message
spend
all
the
time,
but
we
also
mentioned
in
the
autograph
that
we
can
have
a
single
stand
for
both
if
there
is
just
one
message
and
here
what
you
can
find
is
all
these
new
attributes.
We
came
up
with
with
their
descriptions.
We
have
name
clients,
we
have
for
the
requirement
levels
and
yeah,
and
also
it
references
math
per
message
attributes.
So
for
this
case,
this
is
a
single
message
published.
We
say
that
users
should
sorry.
B
Instrumentation
should
put
her
message
spent
on
the
yeah.
Something
is
differently.
It
definitely
doesn't
work
for
me
today.
Anyway,
users
should
put
her
message,
attributes
on
the
published
plan,
and
so
there
is
this.
There
is
this
yaml
who
don't
have
time
to
go
into
any
discussions,
and
they
should
really
do
it
anyway,
but
there
are
more
for
Consumer,
but
we
can
compile
this
yamo
and
we
can
generate.
B
We
can
generate
the
specification
from
it.
So
if
you
look
into
the
row
markdown,
there
are
these
markers
here.
They
match
specific
sections
in
gamma
and
this.
This
is
all
all
between
this
markers
is,
is
generated
from
the
yamu
so
by
updating
the
yaml
I
update
this
back
and
everything
else
is
handwritten.
B
So
basically,
we
can
provide
some
descriptions.
We
can
generate
yaml
from
it
and
it's
much
more
readable
to
this.
Markdown
is
much
more
readable
than
than
yaml
I
just
wanted
to
explain
you
how
how
it
all
works.
B
So
I
think
this
is
more
or
less
complete,
very
rough
draft
of
what
they
think
about
the
single
message
and
I
think
we
discussed
all
the
decisions
there,
but
apparently
we're
all
still
on
on
different
sites,
but
what
I
suggest
we
can
try
to
do
it
in
the
way
that
works
for
single
message
without
introducing
this
Linux
as
if
we
were
updating
the
current
stack,
and
we
can
oh
review
this
document
and
one
once
we
feel
it's
ready.
B
B
C
B
Oh
okay,
so
I
I
will
create
a
piece
I
Wonder
Maybe
in
some
sort
of
a
feature
branch,
because
if,
if
it's
in
my
Fork
then
I,
it
makes
me
kind
of
owner
of
this
thing,
which
I
don't
mind.
It's
just
the
question
of
my
availability
and
plus.
A
B
C
That
sounds
great,
so
we
are.
We
are
over
time.
Peter
thanks,
I
think
we
made
some
really
good
progress
today.
I
think
we
I
will
work
on
this
little
strategy
document
share
it
in
the
open
messaging,
Channel
and
then
yeah.
Let's
hope
for
our
context,
disorder
and
I
think
we
also
made
some
progress
in
like
yeah
cleaning
up
our
house.
We
can
finally
retireable
92
and
then
we
basically
have
this
trade
structure
PR
and
we
will
have
these
attributes.