►
From YouTube: 2022-02-17 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).
C
B
C
Let's
say
give
it
two
more
minutes
we
put
some
time
to
dial
in,
as
always
I'll
put
the
meeting
notes
into
the
chat.
So
please
just
add
your
names
there
and
then
let's
get
started
in
two
minutes.
D
C
Okay,
I
think
we
can
get
started.
I
just
quickly
will
share
the
agenda
so
today,
amir
thanks,
amir
amy,
prepared
like
something
for
talking
about
producer
instrumentation.
So
we
will
start
out
with
that.
So
basically,
that's
we're
trying
to
crash
to
get
like
a
first
grasp
on
this
sorry
trying
to
get
the
first
grasp
on
this
point
here
or
so
like
the
pull
and
push
scenarios,
that's
not
all
yet
figured
out,
but
I
think
it's
just
effective
with
the
work
in
parallel
with
producer
and
consumer
instrumentation.
A
Hi
so
last
week
where
we
started
talking
about
the
producer
side
of
the
messaging
systems-
and
we
can't
hear
you
I'm
here.
A
Yeah,
yes,
yeah,
so
we
showed
a
few
examples
and
discussed
a
few
topics,
and
I
want
to
continue
from
where
we
left
off
last
week,
and
so
I
kind
of
rearranged.
The
document
and
rude
mila
and
johannes
helped
me
a
lot
with
crystallizing
my
thoughts
and
like
creating
the
document.
A
A
So
I
think
that
for
me,
these
are
the
goals
for
me,
maybe
other
people
they
can
disagree
or
have
some
other
things
that
are
important
to
them.
A
So
I
want
to
introduce
this
from
my
point
of
view
and
I'll
be
very
happy
to
hear
more
opinions,
and
so
I
I
have
two
topics
here:
one
for
a
single
message
and
one
for
the
publish
operation,
and
so
if,
if
you're
familiar
with
the
current
specification,
so
the
current
specification,
if
you
were
publishing
a
batch
of
messages,
so
you
can't
know
anything
about
a
specific
message.
So
if,
for
example,
you
send
10
messages
to
sqs,
then
you
know
that
you
will
send
bachelor's
messages
to
sqs.
But
you
know
nothing
about
those
messages.
A
A
I
want
to
know
on
the
producer
side,
I
want
to
have
the
ideas
of
the
messages,
so
I
can
take
these
ideas
and
and
look
for
them
downstream,
for
example,
in
my
broker's
laws,
a
log
file
or
in
some
other
system
which
use
this
id
to
identify
a
specific
message,
and
I
want
to
know
their
message-
everything
that
is
interesting
to
know
about
this
specific
message.
A
So,
for
example,
if
for
one
specific
message,
I
want
to
know
the
destination,
the
routing
information,
how
much
time
it
was
delayed
and
durable
if
it's
durable
quality
of
service.
These
are
all
attributes
that
are
set
by
one
message
and
in
the
producer
side
we
need
to
be
able
to
to
trace
them.
A
So
each
solution.
We
must
make
sure
that
we
can
tell
who
consumed
each
message
on
the
other
side
of
the
consumer,
and
I
want
to
be
to
know
that
the
back
ends
and
the
ui
can
rely
on
consistent
and
stable
method
of
identifying
spam
class
and
process
it.
So,
if
you're
familiar
with
the
current
specification,
so
you
can
look
at
the
spam
kind
and
look
for
a
producer,
but
it's
it's
very
fragile,
like
it's
not
always
working
and
we
need
like
a
stable
way
to
say.
A
If
this
pen
looks
like
this,
then
we
know
that
it's
a
span
of
a
producing
of
a
single
message
and
for
each
method
we
want
to
be
able
to
know
in
which
publish
operation
it
was
produced
to
the
to
the
server
and
regarding
the
publisher
operations.
So
in
my
opinion,
it
should
be
correlated
to
the
exact
method
that
the
developer
is
invoking.
So,
for
example,
if
he's
calling
send
badge
and
they
send
five
messages,
then
we
must
have
like
a
spend
with
this
operation
that
was
invoked
by
the
by
the
developer
and
then
so
so.
A
For
these
operations
we
need
the
attributes,
like
network
attributes,
destinations
rpc
attributes.
These
are
all
shared
by
all
the
messages
in
the
badge,
so
they
can
go
into
the
public
span
and
they
want
to
know
for
a
public
span.
I
want
to
be
able
to
know
which
messages
participated
in
this
publish.
So
if
I
publish
five
messages,
I
need
to
know
who
those
messages
are.
A
I
want
to
suggest
that
we
will
examine
it
with
the
following
metrics,
so
the
first
one
is
number
of
generated
spends.
So
we
know
that
the
spends
are
expensive
to
users.
They'll
usually
charge
the
per
span
and
there's
expensive
to
back-ends
that
need
to
process
them
and
they
can
be
visually
destructive
like
if
you
look
at
the
trace
and
it
has
100
messages
and
it
has
also
100
spends,
then
you
see
a
lot
of
lines.
A
It's
it's
not
the
best
experience
for
users,
and
so
this
is
one
metric,
the
number
of
expense
that
this
solution
will
generate
and
another
one
is
instrumentation
concerns
is
how,
like
we
have
to
make
sure
the
compatibility
of
the
solution
to
popular
libraries
and
patterns
that
are
in
use
in
real
life,
and
then
we
have
to
make
sure
that
the
spend
limits
will
work
well
with
the
solutions
we
suggest.
So,
for
example,
we
have
128.
A
How
will
it
affect
our
solution
and
we
also
have
the
backend
concerns,
so
some
solutions
are
very
easy
to
implement
in
back-ends
they
have
like
very
straightforward
implementation
and
some
solutions
that
will
require
a
more
effort
on
the
back-end
side
and
also
the
performance
and
indexing
like
its
solution,
can
have
different
performance
and
indexing
metrics
in
the
in
the
back
end,
and
the
last
one
is
the
hotel
elemental
model
so
for
its
solution,
like
in
my
opinion,
I
couldn't
find
like
a
best
solution
which
for
sure
is
the
best
one,
so
we
will
probably
have
multiple
options
and
and
some
of
them
they
work
very
well
with,
like
the
current
models
like
of
span
of
links
of
events
and
and
some
of
them,
they
less
make
sense
with
with
their
current
open
telemetry
entities.
A
So
I
want
to
just
like,
from
the
top
level,
just
at
least
a
few
possible
solutions.
Maybe
there
are
more,
maybe
some
of
them.
These
are
very
horrible,
but
I
just
want
to
quickly
go
over
them,
so
one
option
is
to
have
a
single
spin,
a
pair
produced
message.
So
if
I
send
a
batch
of
ten
messages,
then
I
have
like
a
single
spend
for
the
batch
and
then
then
spends
one
for
each
message
that
is
being
produced.
A
This
is
one
option
and
the
second
option
is
ludmila.
Maybe
we'll
talk
about
it
soon
and
the
second
option
is
to
have
a
link,
a
pel
message
and
the
link
it
requires
spam
context,
but
but
we
don't
want
to
generate
a
spam
because
it's
expensive
so
the
the
proposal-
and
I
will
let
mila
talk
about
it,
but
to
have
a
like
a
virtual
context
or
like
a
create
a
spam
context
without
the
spam
itself.
A
Another
option
is
to
use
the
the
events.
So,
for
example,
when
we
send
a
message
we
create
an
event
when
we
get
back
the
app
the
arc,
we
create
an
event
for
it
and
the
last
option
that
I
could
think
about
is
to
use
like
a
span
attribute.
So
if
we
send
10
messages,
we
can
have
like
a
attribute
with
an
array
of
10
values.
Well,
each
value
correspond
to
a
single
message
within
the
batch
and
use
it
as
a
mechanism
to
to
propagate
to
capture
the
per
message.
A
A
A
C
I
agree,
I
think,
when
we
think
about
the
solution,
we
should
probably
have
an
optimized
solution
for
the
single
message
use
case
and
yeah.
Maybe.
A
C
F
C
F
A
Okay,
so
I
want
to
present
to
you
where
one
possible
solution
which
has
his
pros
and
cons,
and
it's
just
one
out
of
a
few
and
so
also
a
quickly
brief
over
it.
So
in
this
solution
we
create
for
each
produced
message
and
we
create
a
one
spam,
and
so
this
this
span
context
it's
used.
It
can
be
used
downstream
for
links,
so
the
link
can
very
easily
point
to
this,
a
single
span
in
the
in
the
producer
side,
and
so
regarding
the
creation
of
this
pen.
A
So
we
talked
in
when
we
talked
about
the
consumer
side.
We
talked
about
whether
the
spam
should
be
created
in
the
instrument,
instrumentation
library,
or
should
it
be
created
by
the
user
code
like
enhanced,
like
in
a
callback.
So
something
like
this.
So
I
want
to
suggest
that
this
these
pens
are
taken
care
of
by
the
instrumentation
library,
so
the
user
doesn't
have
to
wear.
Like
a
add
extra
things
to
his
code,
the
instrumentation,
I
believe
the
sdk
that
is
being
instrument
instrumented,
will
create
those
message
spans
automatically.
A
A
The
spin,
if
if
the
sdk
receives
an
arc
back
from
the
server
saying
like
a
confirmed
confirmation
that
the
message
was
successfully
received
by
the
broker,
then
we
have
to
wait
until
this
acknowledgement
returns
and
then
set
the
status
code
and
the
arrow
on
the
spam.
According
to
the
response
that
we
got.
A
A
So
this
is
the
duration
in
the
status
quo
and
so
regarding
children.
So
this,
like
every
other
spanish,
it
might
be
active
in
like
if
we
create
this
message
and
then
the
context
of
it
become
active
and
some
other
spends
are
generated
underneath
it,
then
there
will
be
the
children
of
this
span,
but
in
most
cases
we
it
will
be
like
it
will
have
no
children,
it
will
be
a
leaf
and
this
pen
will
be
a
producer.
A
And
so
the
pose
of
this
approach
is
that
we
have
like
a
a
very
convenient
place
to
store
all
the
data
that
is
related
to
a
single
message,
all
those
attributes
and
status
code
and
error
message,
and
we
talk
the
duration
very
precisely
per
message.
A
So
it's
easy
to
correlate
producer
and
consumer
because
consumers
they
can
just
create
a
link
to
this
message
in
the
producer
side.
So
it's
very
easy
and
matches
our
open,
telemetry
works
and
and
the
cones
are
that
it's
expensive.
We
will
probably
create
a
lot
of
spends
or
traces
with
like
big
traces
with
many
spans.
A
So
I
I
think
that
in
open,
telemetry,
like
a
span
is
meant
to
track
an
operation
in
the
system,
and
in
this
case
we
don't
have
like
a
very
good
correlation
between
an
operation,
and
this
message
spend
that
we're
suggesting
it's
like
it
doesn't
fit
very
well
into
the
model
and
and
also
regarding
spend
limits.
A
We
will
create
a
lot
of
span.
We
will
have
to
make
sure
that
nothing
bad
can
happen
if
we
reach
some
limit,
and
so
this
is
one
suggestion
and
maybe
ludmila
do
we
want
to
introduce
the
other
suggestions
that
you
we
talked
about.
B
Yeah
one
suggestion
I
have
is
like
so
the
problem
was
the
as
amir
mentioned:
there
are
multiple
crate
for
one
batch
right
and
we've
got
some
feedback
from
users
that
were
like
a
bit
confused
by
the
visualizations
like
this.
So
if
we
want
to
get
rid
of
those,
the
way
to
go
could
be
to
create
a
context
per
message,
but
never
create
a
spam
and
just
create
the
link
on
the
publish
spam
to
the
to
the
context
which
was
never
spent
right.
B
It
will
be
this
the
context
injected
into
the
message,
so
we
will
have
a
similar
link
on
the
consumer
side
so,
like
it
kind
of
mirrors
the
the
consumer
side
in
the
sense
that
it
links
to
the
span,
that
does
not
exist
from
the
same
process
and
yeah.
So
the
the
downside
of
this
approach
is
that
if
we
want
to
say
how
the
span,
how
the
message
ended
in
case
of
partial
success,
then
we
have
to
represent
it
with
an
event
on
the
published.
B
So
when
the
message
is
act
we
will
add
an
event
and
we'll
say:
okay,
this
message,
maybe
with
this
context
or
this
message
id
had
this
outcome
and
then
again
it's
the
question
of
visualization:
how
to
represent
this
partial
success.
B
C
But
then,
but
then
this
basically
will
not
work
on
most
backends
out
of
the
box,
because
basically,
you
have
the
on
the
one
side,
a
link
to
a
non-existing
span
or
to
this
virtual
context,
and
also
on
the
producer
side
and
also
on
the
consumer
side.
You
link
to
this
non-existing
span
so
basically
with
regular
like
backhands
or
support
links.
C
E
But
but
in
this
case,
so
if
I
got
it
correctly,
we
would
create
this
context
and
we
would
attach
it
to
the
to
the
publish
span
that
is
created
or,
like
all
of
the
all
of
these
contexts
would
be
attached
to
the
same.
E
E
The
to
the
non-existing
span
as
well:
yeah,
okay,
yeah,
I'm
not
sure
what
the
impact
of
that
in
in
the
back
ends.
But
you
know
I
mean
that
helps
not
creating
spans
right.
E
This
is
also
something
that
came
up
in
the
so
in
the
pr
that
I
have
for
the
cloud
events,
semantic
image,
which
is
very
very
similar
to
what
we're
discussing
here.
What
you
said
about
the
span,
duration,
so
graham,
actually
commented
or
asked
about
it
like.
What
is
the
duration
of
this
crash
great
span
because
yeah
in
in
my
pr
there-
and
I
think
it's
close
to
what
we're
discussing
there
is-
there-
is
actually
no
duration
right.
E
So
it's
unless
it's
this
scenario
that
I'm
I'm
here
just
said
that
you
can.
You
can
get
a
act
or
something,
but
I
think,
for
example,
for
for
cloud
events,
you
just
yeah.
It
depends
probably
on
the
on
the
protocol,
but
if
you
just
send
it
and
then
you
don't
you,
don't
you
don't
get
anything.
E
So
I
don't
know.
The
duration
also
will
be
probably
always
just
faker,
not
not
well
together.
E
Yeah,
it's
all
optional
right
there,
but
if
you
use
it
with
with
like
a
like
a
with
a
messaging
system
which
is
pretty
much
the
same
right,
then
you-
I
guess
you
will
have
then
you're
just
to
use
let's
say
called
events
to
to
create
the
data
which
is
the
yeah
the
payload.
E
B
E
B
I
just
thought
about
it
now,
I'm
not
sure
if
it's
used
anywhere,
but
the
approach
amir
described
it's
what
we
had
for
in
our
azure
sdks
for
quite
a
while,
and
it's
mostly
working,
but
there
is
some
feedback
that
this
message
stands
for
somewhat
confusing.
Maybe
if
they
had
a
duration,
they
would
be
less
confusing.
A
Third
approach,
so
we
can
discuss
it
so
in
the
third
approach,
the
consumer
spends
the
link
to
the
producer
to
the
producer
and
to
the
singular
producer
span,
which
is
for
the
entire
batch
okay.
So
it's
it's
the
same
way
as
we
as
with
current
specification,
and
then
we
need
to
store
per
message
data,
so
we
can
use
the
existing
spam
attributes
on
the
producer,
spam
and
and
just
test
use
the
arrays.
A
So,
for
example,
if
we
are
sending
messages,
we
create
like
a
messaging
ids
attribute
and
it
will
have
an
array
with
10
values
each
of
these
values.
They
correspond
to
a
to
a
single
message
and
we
will
probably
want
to
have
a
few
of
these
attributes
so
and
then
we
can
correlate
them
based
on
the
indexes.
A
So,
for
example,
if
we
have,
I
don't
know
the
ids
and
the
in
the
status
code
and
maybe
the
delay
seconds,
then
we
will
have
three
attributes
with
the
array
of
ten
values
and
for
each
of
them
the
first.
A
E
Yeah
I
mean
I,
I
think
this
actually
makes
sense,
because
if
we,
if
we,
if
we
create
one
span
for
each
message
it
matches
and
then
on
the
consumer
side
will
link
then
we'll
end
up
with
the
same,
let's
say
confusion,
I
mean
it
depends
how
the
ui
is
module
right,
but
we
end
up
with
this
confusion
right
that
there
is
like
too
many
or
a
lot
of
things,
a
lot
of
messages
and
if
we
have
just
linked
one-
and
this
one
has
all
the
information
that
we
need,
then
maybe
that's
also
good
enough.
E
It's
interesting,
but
I'm
not
sure
if
the
attributes
in
hotel
supports
this
kind
of
structure,
because
this
is
essentially
like
an
object
or
or
some
complex
object,
or
just
we
just
assume.
That
is
a
string,
some
format,
but
yeah
I
mean
I
guess
we
can
also
propose
something
there
right.
So
it
is
valid
to.
E
For
yes,
but
it's
an
array
of
of
of
of
of
string,
yeah
yeah,
so
an
array
of.
C
E
B
A
And
also
the
context
will
be
for
this
single
producer
span,
which
is
for
the
entire
batch
and
like
back
ends
or
uis,
will
have
to
implement
this
extra
step
of
extracting
the
message
they
need
from
this
single
producing
span.
B
C
When
amir,
can
you
share
your
your
list
again
of
the
options,
because
I
mean,
if
I
understand
correctly,
the
first
one
or
the
one
that
you
presented.
Basically,
that
is
that
is
yeah
one
span
per
message,
so
each
message
has
a
dedicated
span,
the
second
one
that
dot
miller
presented.
That
is
like
a
context
per
message,
so
we
don't
have
a
spam,
but
each
message
has
a
distinct
context
and
the
last
two
basically
mean
that
every
every
message
in
this
in
dispatch
has
the
same
context.
C
So
basically
for
the
last
two
options.
It's
basically
every
message
in
the
batch
kind
of
has
the
same
content
text
attached
and
I
think
your
domain,
I
think
problems
I
can
imagine
user
might
have
on
that
solution-
is
that
it
might
be
confusing
when
you
look
at
two
different
consumer
traces
and
they
both
basically
link
to
the
same
producer
span.
C
A
Yeah,
I
agree
so
this
is
one
of
the
cons
for
this
solution,
like
one
of
the
poses
that
we
use
links
link
to
link
to
a
real
spam
so
like
back-ends,
they
can
still
index
everything
with
the
existing
logic
and
they
will
have
a
link
to
something
that
really
exists
and
yeah
and
and
we
we
don't
create
all
those
possibly
many
many
spends
in
the
producer
side,
which
is
also
a
problem
with
the
first
approach.
C
But
also
trust
for
for
my
clarity
here.
So
if
we
are
talking
about
batches
here
so
when
we
talk
about
the
case
of
just
sending
or
publishing
a
single
span,
which
is
also
quite
popular
out
there,
there
we
would
get.
The
wave
is
basically
just
a
single
span
that
would
be
created
by
the
instrumentation
in
the
in
the
messaging
sdk.
C
So
there
would
just
be
publish
a
single
message
and
then
there
is
a
single
span
and
the
context
of
this
band
would
be
used
by
on
the
message,
and
probably
the
duration
of
this
ban
would
be
the
duration
of
the
api
operation.
A
I
think
there's
still
like
a
gap
that
when
the
consumer
received
the
message,
then
he
knows
how
to
link
to
the
producer
via
the
propagated
context,
but
they
don't
know
at
which
index
in
the
producer
array
it
relates
to.
So
unless
we
store
some
ideas
that
we
know
that
can
correlate
the
producer
and
the
consumer.
A
So
it's
still
very
known
standard
where,
if
we
use
the
single
as
spent
producer
message,
then
we
don't
have
this
problem.
We
just
use
the
context
that
will
propagate
anyway
and
we
can
have
a
pure
linking
that
always
makes
sense.
C
B
And
there
was
a
combination
of
things.
The
first
one
is
that
there
were
too
many,
but
also
it
happened
with
the
customers
who
didn't
have
a
consumer
side.
It
didn't
belong
to
them,
so
they
they
never
could
make
sense
out
of
this
because
they
didn't
see
this
messages
continued.
C
I
mean
I,
I
can
actually
see
the
problem,
because
when
you
have
here,
you
have
on
your
on
your
producer
side.
You
usually
have
like
a
trace
that
maybe
has
yeah
five
or
six
bands,
and
then
you
add
the
messaging
instrumentation,
and
maybe
you
send
one
batch
that
has,
I
don't
know,
50
messages
and
then
suddenly,
instead
of
five
spans,
you
get
20
spans.
C
B
Yeah
and
as
long
as
you
have
them
continued
on
the
consumer
side,
you
maybe
appreciate
the
fact
that
there
were
16,
but
if
you
don't,
then
yeah
you're
just
confused
and
paying
for
something
you
don't
need,
but
like
the
link
solution,
it
probably
doesn't
help
with
the
bill.
It
just
helps
with
the
visual
noise,
which
is
the
problem
of
visualization
more
than
the
the
structure,
expense
rate.
A
C
I
think
it
would
be.
I
think
people
might
need
us
some
time
to
to
think
about
that.
I
mean
what
what
we
can
do
or
or
what
what
I
can
do
in
the
old
tab.
I
will
just
put
like
those
four
solutions,
or
actually
it's
three
and
a
half,
because
the
last
two
are
very
similar.
C
I
will
put
that
in
the
old
tap
just
as
a
comment
with
a
short
short
description
and
then
maybe
people
can
post
any
ideas
or
opinions
there,
I'm
not
putting
in
the
other
text
itself,
just
as
a
con
comment
and
then
we
can
have
it
captured
there
and
we
can
discuss
there
and
I
think
it
might
maybe
also
be
helpful
for
people
to
just
see
how
traces
would
look
like
for
some
of
those
solutions
and
then
proceed
on
a
proceed
based
on
that.
C
But
I
think
primarily,
I
think
people
at
least
I
just
need
a
little
bit
to
think
about
that
and
figure
out
what
what
would
make
the
most
sense
or
the
regarding
different
different
use
cases
I
mean
one
thing:
for
example,
it
comes
to
my
mind
is
that
we
are
talking
about
yeah,
auto
ins,
just
having
instrumentation
inside
messaging
sdks,
but
there
are
also
other
use
cases.
For
example,
there's
a
use
case
of
complete,
auto
instrumentation.
C
There
is
no
instrumentation
in
sdk,
but
some
other
component
is
auto
instrumenting
and
with
the
span
produced
per
message,
for
example,
and
the
duration
of
waiting
for
the
for
the
egg
from
the
server
and
putting
this
on
the
span,
I'm
not
100
sure
that
might
be
pretty
complicated
when
just
doing
auto
instrumentation.
C
It
might
also
another
use
case
coming
to
my
mind,
is
that
the
other?
You
have
a
messaging
sdk,
that's
not
instrumented,
and
you
have
to
use
that
and
you
still
want
to
produce
valid
messaging
traces
by
just
adding
instrumentation.
On
top
of
it,
then
also,
you
have
other
challenges
here.
I
think
that's
a
valid
use
case,
especially
in
the
beginning,
because
many
sdks
will
not
offer
instrumentation.
C
Many
sdks
probably
will
not
even
offer
hooks
to
add
instrumentation,
so
customers,
if
they
want
to
have
valid
producer
traces,
they
might
be
just
forced
to
wrap
cars
to
this
library,
and
I
think
that
is
something
we
also
should
somehow
support
and
with
and
also
I
think
in
that
regard,
all
those
solutions
post,
different
challenges
for
those
use
cases
which
I
think
are
are
valid
use
cases
that
you
should
also
aim
for,
and
maybe
others
that
I
don't
currently
have
in
mind.
B
I
also
think
that
maybe
answer
is
like
if
we
talk
about
the
the
first
verse
or
second,
if
you
keep
them
the
context
per
message
that
maybe
both
because
the
problem
that
first
approach
tries
to
solve
as
a
partial
success
rate
that
if
you
can
have
some
messages
sent
and
some
not,
then
it's
useful
to
have
spam
status
on
them,
but
for
the
systems
that
don't
have
partial
success,
what's
the
benefit,
and
maybe
it
covers
like
90
percent
of
the
systems,
then
yeah.
There
is
no
reason
to
carry
the
other
10
percent,
especially.
A
So
maybe
the
benefit
is
that
we
want
to
store
some
attributes
from
the
response.
For
example,
if
the
server
is
creating
the
an
id
for
the
message
and
return
it
as
part
of
the
response,
and
then
we
want
to
use
this
id
as
a
spin
attribute
or
message
attribute
or
capture
it,
some
way
in
the
trace
that
user
can
use
later
to
for,
for
correlating
this
idea
to
something
else,.
B
A
D
One
solution
was
chosen
and
not
the
other.
It's
it's
best
to
have
a.
F
Single
proposed
solution
be
the
focus
but
then
to
to
link
to
alternative
solutions
as
part
of
the
otep.
F
E
But
maybe
we
can
record
this
all
this
outcome
or
all
these
options
somewhere
else?
Don't
we
yeah,
I
mean
we
can.
I
guess
we
can
always
add,
because
I
think
I
saw
in
the
metrics
that
they
had
something
like
this
like
they
had.
Well,
there's
a
I
don't
remember
the
name
now,
but
there's
a
document
with
with
some
data
model,
there's
another
document
with
some
other
things
that
were
like
a
drafty
beginning
that
they
used
to
to
to
go
on.
C
Yes,
this
was
definitely
story.
That's
that's
why
I
just
proposed
to
put
it
on
the
otp
as
a
comment,
but
once
I
I
think
I
would
support.
I
will
propose
that
for
now
that
we
put
it
on
the
other
comments
and
once
we
come
to
conclusion
here,
we
can
basically
put
the
one
solution.
C
They
come
up
with
as
the
proposed
solution,
and
then
we
can
also
add
a
section
like
with
alternative
solutions
where
we
put
the
other
ones,
and
I
think
the
important
thing
is
that
we
have
one
solution
in
there
and
we
give
reasons
why
we
went
with
that
solutions.
I
mean
another
thing
with
the
old
tap,
which
is
on
other
old
tips.
Is
this
outtap
that
you're
working
on
it's
gonna
become
pretty
long,
and
we
should
try
to
make
it
easy
readable
for
people?
F
If
you
look
at
the
template
for
an
otep,
it
includes
sections
for
all
of
this,
but
I
don't
think
it's
it's
necessarily
wrong
to
to
just
briefly
list
the
alternatives,
and
if
we
want
something
more
in
depth,
those
could
just
be
links
to
a
google
doc
or
something
like
that.
E
A
E
A
Yeah,
so
for
you,
I
want
to
suggest
awareness
that
you
you'll
edit,
the
whatep,
and
we
can
all
comment
on
the
otep
and
then
discuss
them
with
all
the
alternatives
and
see
how
we
get
to
a
decision.
E
I
was
also
thinking.
Does
it
make
sense
that,
for
example,
I
don't
know
somebody
or
any
of
us
do
some
research
and
come
up
with
a
list
of
messaging
system
and
how
they
do
batching,
for
example,
how
many
messages
it's
common
to
use
in
a
better,
for
example,
like
amir
said
that
sqs
it
can
send
up
to
10,
but
maybe
if
we,
if
we
have
an
overview
of
how
all
of
the
others
do,
maybe
this
can
help
as
well.
E
I
don't
know
just
came
out
to
my
mind
because
I
I
don't
know
much
about
the
others,
but
I
mean
I.
I
knew
well
the
10
in
sqs,
but
I
don't
know
much
about
the
others
as
well.
A
C
Sense
that
makes
sense
yeah,
and
then
we
can
continue
the
discussion
next
week.
Kevin's
cannot
make
it
today.
He
told
me,
but
maybe
also
he
has
some
input
there
as
like
the
expert
for
more
the
inside
of
my
new
systems,
because
I
remember
he
always
says
that
yeah
once
a
month,
it
comes
like
the
message
comes
on
the
wire.
C
There
is
not
much
you
don't
see
much
of
the
batches
anymore,
that
is
kind
of
resolved
at
basically
the
sdks
sdk
level
in
many
cases,
so
it
might
actually
for
for
from
from
the
point
of
view
of,
like
the
brokers,
be
more
natural
to
have
like
a
single
span
for
its
message.
C
That
then,
can
basically
the
transport
can
kind
of
hook
into
because
then
that's
the
next
question,
like
often
it's
those
brokers
are
very
interested
in
transport,
instrumentation
so
and
having
a
single
spam
or
message,
I
think,
might
make
things
easier
for
them,
basically
to
hook
their
the
transport
layering
but
yeah.
That's
still,
then,
is
the
conflicting
interest
of
users
who
are
then
confused
by
having
lots
of
spans.
There.
F
And
I
really
think
people
will
be
able
to
evaluate
this
stuff
better
if
we're
including
examples
of
like
what
the
trace
structure
is
actually
going
to
look
like
an
actual
implemented.
Prototype
is
like
very
helpful,
so
yeah,
all
of
those
things
really
will
help
us
get
feedback
from
people.
C
Yes,
so
as
next
steps,
basically,
I
would
put
that
in
the
old
tab.
I
wonder
if
anybody
has
some
cycles
to
maybe
come
up
with
some
diagrams
or
sample
traces
until
next
week.
C
Good
volunteers,
we
can.
A
B
Yeah,
I'm
happy
to
do
the
prototypes
of
the
pure
lynx
approach.
A
I
can
sketch
some
diagrams
for
the
way
that
I
imagine
it
will
look
like
for
the
next.
C
Awesome
then,
I
think
we
are
done
with
this
point
for
today,
so
I
don't
have
much
else
on
the
gender
for
the
day.
I
can
just
give
like
a
very
brief
update
about
regarding
the
our
consumer
side.
Instrumentation
that
we
came
up
with
for
this
receive
span.
We
actually
came
like
ludmila
came
up
with
the
solutions
and
the
long
solution
that
we
kind
of
decided
would
be
the
best.
C
This
requires
us
to
add
spans
at
links
after
spank
creation,
so
it
was
putting
our
pr
for
this
pushing
a
bit
also
in
this
back
sick
this
week
and
some
weeks
before,
and
there
is
some
resistance
there.
So,
let's
see
how
that
goes.
C
So
in
the
resistance
comes
mostly
from
like
the
sampling
considerations,
it's
mostly
bog
down
pushing
back
because
at
some
point
in
the
past
it
was
this
ability
to
add
links.
After
spank
creation
was
deliberately
removed
to
kind
of
leave,
possibly
more
nuclear
samplers
to
kind
of
take
all
links
into
account
that
are
put
on
a
span
and
as
a
sampling
efficiency
during
span
creation.
C
So
if
you
want
to
make
a
decision
based
on
all
spend
links
guaranteed,
then
you
need
to
have
our
spendings
present
at
spank
creation.
I
mean
the
community
is
a
bit
divided
on
that.
Basically
bogdan
is
pretty
strongly
pushing
against
allowing
links
after
creation
other
people
like
josh
from
the
sampling
from
the
sampling
area,
saying
no,
no,
it's
going
to
be
fine
here.
I've
already
approved
the
pr.
B
Do
you
think
there
is
something
like
I
can
do
to
help
by
convincing
showing
some
stuff
or
anything.
C
Yes,
I
will
be
back
to
you
I'm
at
this
point.
I
will
think
bogdan
because
he's
the
he's
the
only
one
pushing
against
this
I
mean
he.
He
has
some
good
reasons.
Also
it
was
a
deliberate
decision
made
in
the
past.
So
I
get
that,
but
I
think
from
our
point
of
view,
it
would
just
be
good
to,
in
the
end,
get
the
clear
yes
or
no
answer
whether
we
can
count
on
on
this
feature
at
some
point
in
the
future
or
or
not
so
that
we
can
can
can
move
forward.
F
C
Mean
that
that's
how
I
put
it
out
there
I
said
yeah,
it's
kind
of
having
this
limitation
in
place.
It
kind
of
it
maximizes
possible
the
possibilities
for
future
link-based
samplers,
that's
true,
but
on
the
other
hand,
there's
a
good
out
there
it
it
really
limits
the
current,
like
modeling
capabilities
that
open
dynamite
for
the
basis.
So
it's
just
this.
F
Trade-Off
yeah,
I
mean
I
think
I
would
suggest
I
mean
this
is
true
for
literally
every
other
feature
we
have
on
spans
is
you
want
to?
You
want
to
make
sampling
decisions
based
on
attributes
based
on
span
name
right,
but
actually
all
of
these
things
can
be
added
at
a
later
time.
It's
just
in
practice.
We
want
to
front
load
these
things
as
much
as
we
can,
but
the
reality
is.
C
F
I
think
the
the
issue
here
is
is
just
an
understanding.
F
What
links
are
used
for
right,
like
for
bogdan
links,
were
like
specifically
for
a
kind
of
like
fan
in
sort
of
reduce
step
was
like
their
primary
use
case
at
google
right
and
so
in
their
use
case
you,
you
already
had
them
all
so
he's
thinking,
I
think
mostly
about
that
use
case
and
and
we're
trying
to
expand
how
how
links
are
used
in
general,
so
you'll
notice,
like
anywhere
we're
proposing
to
use,
links,
bogden's
kind
of
challenging
it
a
bit
being
like
why
we're
using
a
link
here.
B
Yeah,
maybe
it
has
like
even
further
implications,
because
I
remember
the
cases
where
we
needed
links
after
spam
has
ended
to
connect
and.