►
From YouTube: 2022-11-17 meeting
Description
Instrumentation: Messaging
A
A
Yeah
he
was
going
to
join
last
time,
but
he
had
some
technical
problems
and
he
couldn't
he
gave
up
so
but
he's
falling
to
June,
because
I'm
lying
so
hi
Dwayne.
B
C
I
I
did
review
the
the
new
PR
lead,
Mill
and
I
had
a
couple
of
very
minor
comments.
One
the
one
thing
like
it's
just
you
know
a
minor
rewording
or
something
but
I,
don't
think
any
can
think
contentious.
But
there
was
one
thing
that
we
may
want
to
discuss
here
today
in
the
pre.
C
This
was
probably
there
before
and
I
just
didn't
realize
it,
but
in
the
Purdue
we
talked
about
the
producer
attribute
to
Consumer
attributes
where
you
talk
about
the
destination
and
the
source
attributes,
and
the
point
that
I
thought
that
I
raised
in
my
review,
that
I
just
submitted
was
that
the
pr
I
think
the
destination
attributes
can
also
apply
to
Consumers
and
that's
kind
of
not
clear
by
reading.
C
What's
there
now
because,
like
if
you've
published
to
a
topic
that
that's
the
destination
that
could
cause
it
to
get
put
on
a
cue
which
is
the
source
for
a
consumer
but
having
the
topic,
information
like
the
destination
in
a
consumer
span
is
useful.
If
that
information
is
available,
so
I
think
we
could
just
add
a
section
to
the
consumers
attributes
just
saying
that
if
the
destination
attributes
are
known
in
the
messaging
system
that
they
can
be,
they
can
be
provided.
A
Yeah
that
I
will
add
it.
Do
you
think
it's
possible?
The
opposite
is
possible.
If
consumer
attributes
are
known
on
the
producer.
C
That
I
I,
don't
think
so
unless
the
messaging
system
is
such
that
it's
one
to
one
and
and
the
destination
The
Source
are
the
same
thing
and
if
that
I
mean
I,
I'm
kind
of
you
know
going
off
the
cuff
here,
a
little
bit
But.
Ultimately,
that
requires
the
producer
to
know
things
about
what
the
broker
is
going
to
do,
which
is
generally
not
the
case.
A
Cool
so
I
will
add
the
destination
attributes
can
be
present
by
consumers.
If
no
and
that's
it,
it
does
not
stop
someone
from
adding
any
other
attributes
right.
So
we
are
describing
the
minimal
set
and
the
rest
can
be
added
diffusers
want
to
if
the
instrument
menu
right,
yeah,
awesome,
I,
hope
those.
D
D
Here
so
I'm
not
sure
if
we
will
have
much
to
discuss
about
this
PR
ude
she
just
you
know
some
remarks
from
the
NSC.
That's
great,
so
you
know
Electro
skills
data
PR
of
this
new
one
noticeable
draft
dot
is
a
actual
PR.
So
let's
see
what
other
feedback
we
get,
there
will
also
give
this
one
another
review
as
soon
as
possible
and
please
give
everybody
else
to
the
same.
D
A
Yeah
I
recall:
we
agreed
on
some
parachas
that
we
need
to
see
or
mentioned
all
the
messaging
query
group
members
and
ask
for
their
approvals
right.
So
I
guess
I
will
mention
you
folks
and
also
Bruno
right.
Do
we
need
to
do
anything
else
on
the
formal
side.
A
D
Think,
let's
start
off
with
that,
I
think
it's
everybody
here
in
that
meeting
so
can
go
on
there.
Bruno
can
go
on
there
right
that
should
that
should
be
fine,
I,
hope,
okay
and
that's
just
a
wrong
question
here
regarding
the
pr
as
a
whole,
I
think
this
now
contains
all
attribute
related
changes
that
we
intend
to
do
with
this.
Pr
is
merged.
We
are
more
or
less
done
on
the
attribute
side.
C
I
I
think
that
we
were
talking
last
week
about
how
like
I,
had
a
comment
on
the
other
PR
about
maybe
more
crisply
defining.
What
message
ID
means
I
think
it's
important
to
Define
that
and
we
kind
of
decided
that
this
PR
is
limited
in
scope
to
restructuring
of
the
attributes
and
that
further
kind
of
refinement
on
on
you
know,
definitions
and
meanings
could
be
deferred.
C
If
we
want
this
to
be
the
final
one
I
that
we
that
we're,
we
consider
this
finishing
the
attribute
changes,
then
it
would
be
nice
to
kind
of
clarify
some
of
that.
A
little
bit
more
and
I
would
probably
pay
a
little
more
closer
attention
to
the
definitions,
because
when
I
first
encountered
the
original
spec
and
started
trying
to
implement
it,
I
found
some
of
the
definitions
a
little
bit
vague
and
hard
to
know
exactly
what
was
meant
by
them.
A
Yeah
Dwight
I
agree:
it's
not
the
absolutely
final
state
of
attributes.
I
think
this
is
about
the
breaking
changes
or
some
critical
things
that
we
wanted
to
bring
in
would
definitely
we'll
need
to
introduce
more
I
think
we
miss
a
lot
about
settlement,
so
we
will
need
to
add
more
attributes
regarding
the
message.
Id
I
I
started
some
online
conversation
with
you
and
the
thread
from
the
other
PR.
Maybe
I
will
ping
you
on
slack
to
share
the
link.
C
D
That
sounds
great,
so
we
have
message
ID
to
answer
you.
Do
you
see
any
other
other
attributes
here
that
maybe
need,
or
do
you
already
have
any
other
open
issues
in
mind
that
maybe
need
for
the
discussion.
C
Sorry
I
was
just
going
to
say
that
I
think
one
of
the
others
we
talked
about
doing
with
regards
to
attributes
was
to
split
out
the
system,
specific
ones
kind
of
out
of
this
back
and
into
their
own.
But
that's
again
not
in
the
scope
of
this
one
and
then
I
I,
I
sort
of
didn't
look
closely
and
evaluate
the
definitions
of
each
attribute.
C
Once
we
sort
of
agreed
that
the
scope
of
this
was
just
the
restructuring
so
I,
if
we
want
to
have
a
list
of
ones
that
I
would
like
to
discuss
later.
I'd
have
to
maybe
just
go,
take
a
closer
look
but
message:
ID
is
the
one
that
jumped
out
to
me.
B
Okay,
yeah
I
have
a
question.
I
commented
on
the
previous
PL
I
see
that,
for
example,
for
Kafka
we
have
a
messaging
Dot,
kafka.message.partition
and
I.
Wonder
if,
like
the
politician,
should
go
into
the
message
name,
space
or
into
the
destination
and
the
source.
A
Can
I
reply
to
your
comments
so
from
API
perspective?
Partition
is
a
property
of
message,
so
you
can
have
like
it
describes
a
message
right
and
if
it's,
it
would
be
very
confusing
to
edit
on
the
destination
or
source.
C
In
my
experience,
the
partition
is
like,
like
that,
the
message
might
have
a
key
or
information
that
affects
the
partition
that
goes
on,
but
it
isn't
it
describing
like
it's.
If
it's
going
on
a
partitioned
queue
like
which
partition
of
the
queue
that
it's
going
on
foreign.
A
D
D
A
I
think
our
you
have
a
batch
from
different
topics
as
well.
Right,
I,
think
the
destination
is
is
special
because
it's
generic
right,
it's
not
Kafka
specific,
and
we,
we
kind
of
feel
it's
so
generic
that
we
even
wanted
to
make
it
required,
at
least
wherever
we
can
and
Kafka
partition
is
Kafka
specific
and
then
it
should
describe
where
it
lives
in
Kafka.
That's
my.
D
A
D
B
I,
don't
think
it's
it
really
matters.
But
for
me
it
was
a
bit
strange,
like
I.
Imagine
the
politician
to
be
like
a
female
to
the
topic,
name
or
qname,
which
we
make
sense
for
us
to
host
under.
C
B
B
Name,
space
because
I
I
think
it
likes
belongs
to
the
same
area
like
how
the
broker
routes
or
or
process
the
the
message-
and
it's
not
like
something
that
identifies
the
message
like
I,
don't
know,
maybe
the
the
payload
size
or
the
ID,
or
something
like
this
in
my
mentor
model.
It's
like
a
property
of
the
message
itself,
but
the
partition
is
just
the
property
of
how
the
message
is
outed
or
handled
in
the
bokeh
OR
stored
or
transmitted.
B
C
Yeah
I
think
just
to
what
you're
getting
at
Amir
is
something
that
I
thought
and
I
almost
added
a
comment
in
the
pr
review,
but
I
just
kind
of
figured
it.
It
I
I
feel
okay,
as
is,
but
that
it's
somewhat
arbitrary,
that
destination
kind
of
isn't
inside
message
right
that
it's
not
messaging.message.destination
like
because
it
is
the
destination
or
the
source,
is
sort
of
a
property
of
the
message
you're
sending
or
receiving.
C
But
that
adds
a
lot
of
hierarchy
and
if
everything
is
perceived
to
be
part
of
the
particular
sender
receive
operation,
and
we
agree
that
for
batches
that
you
need
to
you
can't
put
a
destination
in
the
messaging
name
space.
Unless
it's
applies
to
all
messages
in
the
batch,
you
know
I,
guess
that's:
okay,
I
guess
what
we're
saying
is
the
destination.
C
Namespace
is
something
that
might
apply
to
everything
in
a
batch,
but
may
not
and
and
I
agree
that
when
you
send
a
message,
you
specify
that
where
it's
going
and
in
kafka's
case,
maybe
the
partition
and
and
everything
else,
but
it
is
more
related
to
how
the
broker
is
going
to
process
it
and
store
it.
And
consumers
are
going
to
get
it
like
through
destination
and
Source.
Then
it
is
truly
a
property
of
the
message
itself.
C
I
I,
don't
know
if
it's
worth
debating
here
too
much
because
I
feel
like
the
system-specific
attributes
are,
are
really
I.
Think
we
should
be
trying
to
consider
those
out
of
scope
of
what
we're
doing,
I
think
we're
trying
to
come
up
with
the
core
messaging
spec
and
eventually
Fork
these
things
off
into
their
own
per
system
specifications,
and
and
that
when
we
do
that,
that
would
be
the
best
time
to
debate
these
points.
A
Yeah
and
I
also
think
we
can
I'm
not
sure
like
what
would
be
the
driving
Factor
here.
For
me,
it
sounds
like
if,
for
yeah
for
system
specific
attributes,
namespaces
is
the
way
for
a
backend
to
understand
at
least
some
semantics
about
those
attributes.
Right
and
backends
can
see.
Okay,
this
this
leaves
the
message
name.
Space
then
probably
I
should
show
it.
I
should
expect
it
on
links.
I
should
show
it
and
per
message
you
or
something.
A
If
it's
destination,
maybe
you
should
show
it
on
the
like
I,
don't
know
the
edge
between
different
nodes,
and
then
it
doesn't
apply
there
other
than
that
there
it
like
for
for
end
users.
It
maybe
doesn't
matter
it's
more
like
for
the
backends
to
give
some
meaning,
and
it
doesn't
have
to
deeply
describe
how
broker
Works
internally,
it's
just
something
that
makes
sense
to
users
and
Records.
B
B
B
A
D
D
That's
why
we
split
it
out
in
separate
documents,
but
I
agree
with
not
Miller
that
we
should
avoid
to
introducing
something
here
that
that
might
break
again
in
the
future,
because
earlier
that
is
just
a
question
that
other
people
might
bring
up
per
review
to
PR
and
I
mean
we
should
have
kind
of
some
some
coherent
answer
from
work
group
site.
B
B
That
that
describes
the
routing
or
how
the
the
and
there's
the
the
message
and
the
process
it
and
store
it
and
Route
it
and
do
and
anything
that
in
this
area,
it
makes
sense
to
me
to
go
into
the
destination
and
source.
Namespaces
and
message
should
describe
like
something
that
is
like
a
property
of
the
single
message
itself
like
the
idea
is
a
good
example
and
the
payload
size,
something
that
is
for
sure,
like
it,
belongs
to
a
message.
B
And
that's
that's
makes
sense
to
me.
A
A
D
And
that
before
we
go
into
that
one
more
question
to
you
I'm
here
when
you
say
this
should
be
destination
specific
it
partition,
it
should
still
be
Kafka
specific,
so
The
Ledger
should
be
messaging.cast.destination.partition
yeah.
That's
my.
B
Even
if
you
consume
a
message,
and
you
see
the
routing
key
on
when
you
consume
the
message,
so
the
routing
key
describes
well,
the
message
was
like
when
someone
sent
the
message,
how
it
required
for
it
to
be
routed,
and
it's
a
good
example
of
what
the
Edwina
stated
in
the
beginning
of
this
meeting
that
the
when
you
consume
a
message,
you
may
still
have
like
a
destination
attributes
on
it,
so
the
routing
key
could
be
a
good
example
to
I.
Think
for
this
right.
When
does
it
make
sense
to
you.
C
I
I
think
so:
I'm
not
super
familiar
with
rabbit,
but
basically
what
you
described
I
think
it
does
sound
like
something
that
you
know
belongs
as
a
destination.
It
would
Naturally
Fit
there.
A
C
B
B
So,
for
example,
you
send
a
message
with
a
routing
key:
let's
say
it's
a
log
record
and
you
say
info
and
then
a
queue
can
say:
I
want
to
fetch
all
info
messages
and
another.
You
can
say:
I
want
to
fetch
all
messages
and
no
matter
what
the
routing
key
is
and
another
one
can
say,
I
want
all
those
that
starts
with
an
I
and
then
you'll
like
send
a
message,
and
you
said
this
is
an
info.
This
is
the
routing
key
and
it
gets
sent
to
the
relevant
cues.
B
So
I
don't
think
routing
is
relevant
on
the
source.
It
just
tell
you
which
routing
key
domestic,
like
was
populated
on
the
message
when
it
was
sent.
I
think
I'm,
not
an
expert
I,
just
use
it,
and
and
remember
that
this
is
how
it
works.
B
A
C
I
think
it
should
be
like
what,
where
who
said
it
and
like
if
it
was
set
on
the
destination
like.
Ultimately,
it
is
a
property
of
the
message
right
so
I
mean
you,
but
you
can
make
that
case,
I
think
for
everything
related
to
source
and
destination.
We
split
out
those
namespaces
to
say
these.
These
are
semantically
or
cognitively
or
something
it
was
sent
to
or
where
it
came
from
and
I
think.
The
routing
key
definitely
sounds
like
something
is
where
you
directed
the
message
to
go.
A
Yeah,
it's
just
very
hard
to
come
up
with
some
generic
approach
here.
If
you
need
to
look
into
every
specific
broker
and
understand,
what's
message
what's
destination,
we
will
never
be
able
to
achieve
any
progress
and
like
if
I
look
into
the
documentation,
I'm
going
to
paste
the
link
in
the
chat.
This
is
the
rabbit
and
Q
message,
attributes
and
payload.
A
A
A
The
destination
and
Source
are
super
they're
super
special
they're
generic.
They
don't
talk
about,
however,
specific
blogger
works
and
we
can
even
entertain
the
idea
that,
if
it's
common
for
every
message
in
the
batch,
it
goes
by
destination
name.
If
it's
specific,
it
goes
into
message
name
space,
and
then
we
can
entertain
this
idea.
But
I.
C
Guess
my
point
is:
is
that,
with
the
topic
like
in
JMS,
you
can
set
the
topic
on
a
message
right,
it's
property,
the
message
so
by
the
by
the
argument
that
that
writing
key
should
be
in
the
message,
because
it's
a
property
of
the
message.
The
same
goes
for
Topic
in
which
and
then
you
start
to
pull
everything
in
destination.
Out
of
you
put
it
in
the
message
and.
A
A
That
that
that's
fine
I
I
don't
have
a
very
strong
appeal,
no
actually,
no
so
routing
key.
If
we
use
this
framework,
routing
key
is
listed
in
Revit
documentation
as
message
attribute,
so
it
should
go
to
message.
A
C
A
C
C
It's
it's
not
clear
when
something
specific
should
go
in
destination.
Namespace
versus
the
message,
namespace.
A
So
I
think
the
key
distinction
between
destination
and
message,
especially
for
batching
cases.
What
goes
where
message
goes
on
link
our
destination
are
stars.
Go
on
span
right.
This
is
a
single
case,
it's
mixed,
but
that's,
let's
think
about
batching
case.
So
we
believe
that
in
absolute
majority
of
cases
there
is
one
destination
and
one
source
for
all
messages
in
a
batch
right.
That's
why
we
have
this
destination
and
Source,
honest
pen.
C
That
that
doesn't
sound
right
to
me
definitely
for
Destination
on
a
consumer
I
would
expect
that
it
would
be
common
to
have
different
destinations
for
messages
on
a
consumer
span.
C
Possibly
both,
but
if,
if
you
I
I,
don't
have
a
lot
of
experience
with
apis
that
de-batching,
but
so
if.
But
if
you
were
to
tell
me
that
it's
uncommon
to
have
that
on
almost
all
cases,
it's
going
to
be
the
same
source
for
a
consumer.
I'd,
say:
okay,
fine
I'll,
defer
to
your
experience,
but
I
wouldn't
buy
that
for
those
messages
consumed
that
they
would
have
the
same
destination.
C
I
would
think
it'd
be
very
common
to
come
from
different
destinations,
but
unless
you're
using
a
messaging
system,
that's
very
point-to-point
and
the
source
and
destination
is
the
same
thing,
but
for
a
pub
sub,
where
you're
publishing
the
topics
and
the
broker
inspects,
topics
and
decides
which
cues
to
put
them
on
it
would
be
common
for
a
queue
to
get
messages
from
different
topics
and
that
receiving
a
batch
from
one
cue
would
mean
you're
receiving
a
batch
of
messages
that
have
different
destinations.
C
B
Yeah
just
to
to
summarize
my
my
ass
point
on
this
I,
don't
think
it's
super
important
I'm
good
with
both
options,
but
that
just
my
personal
view,
I
think
it
makes
more
sense
to
me
to
have
like
these
things
on
the
destination
and
the
source
open
the
message,
but
it's
not
a
blocker
or
I,
understand
your
point
as
well.
So
whatever
we
decide,
I'm
good
with
it,
I
don't
want
to
block
this
anymore.
With
this
PL.
C
Don't
know
yes
yeah,
so
I
was
just
saying
that
I
I
think
it
would
be
a
mistake
to
assume
in
the
specification
that
the
all
messages
in
a
batch
who
have
the
same
destination
and
same
Source,
even
if
it's
very
common
I
mean
to
me
batch,
is
a
collection
of
messages
that
are
received
and
that
we
shouldn't
assume
about.
You
know
what
the
messaging
system
has
put
in
a
batch.
A
For
me,
it's
important
to
come
up
with
some
generic
approach
like
if
one
of
you
can
like
so
without
going
into
details
about
each
particular
system.
There
is
nothing
we
can
do
if
we
look
into
this
level
too
deeply
right.
What
would
be
your
guidance?
We
can
give
to
instrumentation
orders
that
could
help
them
understand
where
they
should
put
specific
attribute.
C
A
A
C
Well,
that's
sort
of
the
question
I
had
is
you
know
we
we
haven't
defined
sort
of
what
what
belongs
in
destination
and
what
belongs
in
Source
I.
Think
we
sort
of
have
an
idea
right
like
and
and
when
it
comes
to
system
specific
things
I
think
we
should
leave
it
up
to
the
system
to
decide
whether
this
is
like
effectively
an
attribute
of
the
source,
an
attribute
of
a
destination.
A
C
A
C
Right
so
I
think,
and
that's
really
the
destination
is,
is
something
that
affects
the
broker's
behavior
and
directing,
where
the
message
goes
and
attribute
of
a
source
is,
is
something
that
defines
where
the
message
came
from
right
on
a
broker
yeah.
A
C
Don't
know
does
it
affect
where
the
message
goes
or
where
it
came
from
I
mean
it
can
affect
whether
it
gets
let's
say
discarded
or
something
like
that,
but
it
it
doesn't
say
because
I
think
deduplication
is
sort
of
a
transport
problem
and.
C
C
A
Oh
okay,
so
let's
get
back
to
the
initial
question!
What
like
what
you're
telling
to
to
spark
alter
for
a
specific
system
is
to
know
what
the
FedEx
broker
Behavior,
what
the
facts,
application,
behavior
and
based
on
this.
If
it's
a
broker
thing
that
maybe
put
it
in
the
destination
and
source
and
if
it's
application
layer
put
it
a
message.
A
B
I
can
share
my
my
I
think
that
they're
messaging,
their
namespace,
should
hold
things
that,
like
like,
are
expected
to
be
unique,
better
message
like
like
the
ID,
it's
it's
something.
Each
message
will
have
like
a
different
value
or
expected
to
have
a
different
value
and
also
the
payload
size.
It's
not
something
that
shared
with
few
messages.
It's
like
unique
per
message
like
it
can
by
chance,
be
the
same
value
for
a
few
different
messages,
but
it's
it's
Unique
per
message.
B
B
So
routing
key
doesn't
belong
to
a
message
in
my
opinion,
because
it's
it's
logically
like
a
lot
of
messages
is
like
possible
and-
and
it's
I
think
common-
that
they
share
the
same
routing
Key
by
Design,
because
it's
like
a
property
or
not
of
the
message,
but
there
of
the
system
like
how
you
how
you
decide
about
routing
you
like
decide.
You
have
a
routing
key
and
you
have
a
lot
of
messages
that
use
the
same
routing
key.
So
it's
not
something
specific
to
the
message.
B
B
B
Its
as
this
attribute
by
chance,
like.
A
A
B
Temporary,
if
you
send
a
message
with
like
a
temporary
or
Anonymous
or
like
this
message,
gets
an
attribute
and
it's
Unique
for
this
message.
You
generate
it
for
one
message
and
you
like
join
it
with
this
message,
and
it
belongs
to
this
message
and
the
next
message
we
used
another
temporary
destination.
Then
then
it
makes
sense
to
me
to
be
hosted
in
the
message
name,
space,
I,
hope,
I'm,
clear,
I'm,
not
sure.
A
Yeah
I
think
you
are
Johannes.
Would
you
mind
opening
the
link
that
I
posted
in
the
chat
I've
previously
collected
some
attributes?
That
probably
should
go
and
message,
and
there
are
a
bunch
of
them
that
would
not
follow
this
guidance
like
reply
to
Priority,
TTL
delivery,
remote
redelivered,
user,
ID,
content,
type
content
and
quoting
expiration
time
or
respiration
time
is
Maybe
and
many
others
in
this
list
that
are
that
exist,
at
least
in
some
more
or
less
common
things.
A
So
if
we
use
this
approach,
then
somebody
who
operates
a
specific
extension
for
a
semantic
convention,
so
it
need
to
go
really
deeply
and
understand
what
like
how
each
of
these
things
work
and
if
they
apply
to
their
new
unique
per
message.
Where
would
you
put
Priority
it
belongs?
It
describes
the
message:
it
does
not
describe
a
destination,
but
it's
common
across
multiple
messages.
B
So
I
don't
think,
there's
a
lot
of
damage
if
things
are
hosted
in
the
wrong
namespace
like
it's,
it's
flexible,
like
someone
can
make
a
decision
and
things
will
keep
working.
My
only
suggestion
is
to
like,
in
the
formal
specification
to
to
understand
the
the
reason
we
we
decide
to
put
each
attribute
in
each
namespace,
so
we
have
like
consistency,
and
at
least
it
makes
sense
to
us
like.
If
people
want
to
do
other
things,
it's
not
a
big
deal
like
they
can.
A
D
Mean
I
would
say
here
it
it.
It
makes
a
bit
of
a
difference
besides
attribute
naming
because
I
mean
they
say
that
message:
okay,
that's
kind
of
a
especially
if
the
message
namespace
is
that
it's
actually
can
go
on
every
link
or
event,
and
if
you
have
rapidmq
destination,
we
say:
okay,
that
actually
should
be
on
the
span.
D
So
I
think
it
makes
a
difference
here,
but
What
what
we
prescribe,
except,
of
course
we
go
to
extreme
route
and
we
say:
okay,
there's
just
message:
dot
destination,
Dot,
routing
key,
but
but
I
think
here
there
is
kind
of
a
difference
that
goes
beyond
just
the
plane
semantics,
but
that
also
impacts
where
this
attribute
goes
and
I.
D
Think
in
this
in
this
regard
it's
quite
important
to
or
we
might
actually
break
people,
we
might
make
it
hard
to
adapt
if
it
was
changed
it
later
from
message
to
destination,
and
just
one
thing
I
want
to
bring
up
here.
I,
don't
have
a
too
strong
opinion
on
that,
because
I
think
from
the
customer
point
of
view,
the
difference
wouldn't
be
that
big,
but
I
think
that
I
agree
with
Mila
that
we
should
see.
This
should
see
this
destination
namespace.
That's
somehow
special,
because
that's
also
this
destination
name.
D
It's
also
what
goes
on
to
the
span
name
in
some
instances.
So
in
that
regard,
this
is
just
some
how
to
say
a
compromise
or
simplification
that
we
have
to
kind
of
just
protect
the
user
from
some
cognitive
overload
and
just
provide
him
like
a
simple
view
on
like
a
complex
underlying
system.
D
So
in
that
regard,
I
think
we
should
see
this
destination.
Name
is
somehow
special
and
I
agree.
If
we
would
go
all
the
way
and
try
to
be
really
accurate
and
consistent,
we
actually
would
need
also
make
a
destination
like
a
message
specific
sub
namespace,
and
you
have
then
this
destination
on
each
single
message.
That
might
be
the
more
accurate
view
to
model
it.
The
quest
is
just
so
much
benefit.
Does
this
bring
to
a
user?
It
would
probably
just
be
more
confusing.
D
And
also
some
like
from
again
from
the
user
point
of
view
to
print
it
up
is
when
I,
when
I
use,
let's
say
some
kind
of
thinking
about
the
API
again
and
then
I
say
usually
I
say:
yeah
I
want
to
receive
messages,
I
Define
the
destination
and
they
give
like
a
name
for
the
destination,
maybe
URL
or
whatever,
but
I
think
that
I
give
the
partition
on
this
level.
D
That
is,
in
my
opinion,
at
least
an
exception
like,
if
there's
the
possibility,
of
course,
but
I've
seen
people
doing
that
very
rarely
and
I
think
that
is
for
me
from
the
user
point
of
view,
probably
like
the
question:
what
makes
a
destination
from
the
user
point
of
view,
it's
kind
of
what
I
Define
to
just
receive
messages
and
I
would
say
for
I
can't
give
any
number,
but
maybe
for
98
of
the
users.
The
petition
is
not
part
of
that.
D
That
is
just
something
that
they
see
on
the
message
and
that
is
abstracted
away
from
them.
Verse,
of
course,
I
mean
when
we
kind
of
work
a
lot
with
messaging
systems
and
when
you
know
like
messaging
system
internals,
a
partition
might
be
a
very
Central
concept,
but
for
the
user
in
I
think
the
majority
of
the
cases.
It's
not.
C
I
I
would
Echo
that
because
well
we're
we're
implementing
a
person
queue
and
that
we
don't
even
have
a
way
of
a
user
setting
the
partition
of
the
queue
right.
The
system
decides
the
partition
and
it's
all
about
maintaining
order.
It's
it's
a
way
of
ordering.
You
know
preserving
order
within
messages
in
the
key,
so
I
do
agree.
It's
a
detail
that
most
users
don't
care
about.
I
agree
with
that
for
partition,
but
in
the
case
of
destination
mentors
are
we
saying
that
those
cannot
go
on
the
per
message?
C
Links
for
batches.
C
A
So
like
it
may
be
one
thing,
I
heard
kind
of
implicit
that
maybe
it
makes
sense
for
Destination
name
to
have
to
be
called
destination
name
when
it's
on
spam
and
called
something
else.
When
it's
on
a
specific
message,
if
you
want
to
stay
pure.
D
Just
to
be
cute
here,
I
think
destination
name
is
currently
a
required
attribute
into
span.
A
D
A
D
B
And
also
sometimes
there
will
be
messaging
destination
name,
sometimes
messaging,
Source
name.
D
B
Okay,
I
want
to
summarize
that
I'm
really
happy
with
this
PL
I
think
it's
a
really
good
and
I
think
both
like
all
the
options
that
we
describe
will
do
good
work
and
I'm
really
happy
with
the
focus
that
SPL
blinks.
A
Yeah,
thank
you.
So
we
are
we
fine
with
this
purpose,
or
do
it
like
I
understand
that
the
destination
and
Source
will
kind
of
agree
that
that's
a
special
thing
right?
Do
we
want
to
discuss
more
offline?
Each
specific
message
attribute,
then
move
things
around
and
happy
to
change
routing
to
the
destination.
There
is
actually
a
PR
from
some
guy
who
wants
to
put
it
in
others.
So
maybe
we
should
make
sure
we're
on
the
same
page
with
him
as
well.
B
A
A
A
A
Yeah
so
I'm
talking
about
lines
348
and
four
lines
there.
So
are
you
happy
with
this
description
or
do
we
need
to
be
more
specific
and
make
it
more
complicated?
A
B
D
Think
the
description
is
fine,
it's
just
I
think
the
main
the
main
question
we
used
to
working
here
to
see
about
this
message
specific
and
what
is
destination
specific
I
think
it
is
that
that
everything
message
specific
should
go
there
and
that
everything
destination
specific
should
go
there.
I
think
that
is,
that
is
out
of
dispute.
I
think
we
agree
there,
but
you
think
about
this
message:
specific
and
body
station
destination,
specific
I
think
that
is
where
and
and
I
think
I'm
with
what
you
put
here.
D
I'm
fine,
because
I
mean
to
to
a
certain
extent
yeah
being
a
bit
awake
into
spec
just
gives
10
implementers
like
some
kind
of
some
freedom
to
to
do
their
own
thing,
instead
of
being
too
restrictive
but
yeah.
If
not.
If,
if
it's
not
even
really
queer
for
us,
what
is
going
there,
I
I
think
this
channel
formulation
is
fine.
It
boils
them
down
to
problems.
When
you
look
at
the
individual
attribute
and
ask
you:
where
does
it
go
now?
Is
its
message,
specific
destination,
specific
Source,
specific
batch,
specific?
D
A
Cool
yeah,
so,
okay,
this
is
big
enough
just
enough
and
then
basically
we're
saying
that
we
are
experts
enough
in
certain
systems
that
we
can
make
even
better
decisions
than
just
the
API
public
API
service
right.
A
So
we
we're
going
to
do
a
special
thing
for
the
ones
that
we
have
in
the
spec,
but
we
will
just
give
all
the
freedom
to
someone
who
creates
in
new
extensions
to
interpret
this.
D
Okay,
yes,
I
mean
what
I
will
put
on
the
on
the
to-do
list
and
I
hope
I
will
have
some
time
for
that
until
next
week
is
that
we
just
try
to
maybe
to
to
to
come
up
with
some
kind
of
prototype
based
on
this
on
this
new
semantic
conventions,
I'm,
not
sure
if
you
already
did
look
below.
D
A
D
A
D
C
B
D
And
I've
also
try
to
that's,
that's
still
a
gap
on
my
side
and
try
to
understand
your
how
to
exactly
set
look
at
the
requirement
levels
of
those
destination
attributes
because
I
didn't
wander
for
the
ideas
we
had
about
span
names
when
we
have
this
case
where
the
destination
is
not
on
the
span
but
on
let's
say
just
maybe
the
answer
links
because
it's
not
required.
D
D
C
I
do
think
spam
names
are
something
that
we
kind
of
know
we
have
to
discuss
and
we
want
to
look
at
and
I
guess.
What
you're
saying
here,
though,
is
we
want
to
say
to
kind
of
keep
the
specs
saying
with
GIF
this
PR
pulled
in
that
we
want
to
make
sure
that
that
it
makes
sense,
but
but
that
will
still
revisit
it
later.
A
D
So
I
have
a
one,
as
we
have
two
minutes.
Two
minutes
left
a
general
question.
Now.
How
should
we
continue
the
offline
discussion
on
this
PR?
Should
we,
as
this
PR
is
like
now,
public
and
people
can
like?
Basically
it's
open
for
General
video.
D
Should
we
continue
our
discussions
on
this
PR2
or
should
we
create
separate
issues
for
for
these
discussions,
for
example
the
the
discussion
with
here
about
like
a
destination
or
message
specific
attributes,
because
I
think
we
should
capture
it
somehow,
but
they're
not
sure
if
we
should
do
it
on
the
PR,
but
or
it
should
be
open
like
a
separate
issue,
to
keep
that
apart.
B
Think
where
we
discuss
it
in
the
group-
but
maybe
other
people
in
the
community
also
have
comments
on
this
issue,
so
it
could
be
good
to
to
have
them
over
reviews
to
help
us
converge.
A
Yeah
sure
I
mean
one
thing:
I
would
like
to
propose
that
it's
it
seems
there
is
a
strong
opinion
that
specific
attributes
right
routing
Keys
should
be
on
the
destination.
A
If
you
can
leave
your
comments
there,
that
would
be
great
I,
I'm,
not
sure
I
I,
remember
everything
that
we
discussed
with
regard
to
every
attribute
and
yeah,
so
I
I,
don't
know.
I
can
capture
the
this.
Some
some
decisions
were
made
inside
this
pull
request.
Just
add
an
extra
line,
saying
that
okay
is
your
best
judgment.
I,
don't
know,
I,
don't
know
informal
thing,
because
your
best
judgment
to
decide,
depending
on
your
defects,
partition
a
specific
broker
and
take
these
things
into
account.
D
I
mean
I
I
can
add
in
some
comments
on
the
pr
capturing
discussion,
but
we
have
based
on
this
attributes
and
I
mean
for
if
you
have
it
on
the
priority
info,
routing
key
I
mean
I.
Still
there
was
this
one
guy
from
rabbitmq
that
joined
us
some
time
ago.
I
will
ping
him,
then
maybe
he
can
give
his
opinion.
D
D
D
Team
itself,
knowing
that
this
person
involves
in
a
Cisco
yeah,
there's
one
person
from
Rapid
itself
and
I
mean
it
would
just
be
interesting
to
like
get
their
opinion
from
Rapid
forms
itself.
I
think
he
is
for
them
whether
they
see
this
a
message
attribute
bound
to
the
message
or
whether
to
exceed
more
path
to
the
destination
and
then
for
partition.
I,
don't
know
any
Kafka
Forks,
but
I
think
that
is
a
more
General
problem
that
we
and
we
all
have
a
better
understanding.
D
Four,
but
at
least
for
the
routing
key
I
can
contact
this
rabbitmq
guy
and
see
what
they
say,
yeah
and
then
let's
go
from
there.
Maybe
we
get
some
good
good
input
from
the
community
that
helps
us
actually
to
move
forward
here.
B
But
I
don't
think
it's
specific
to
the
messaging
system
implementation,
it's
more
like
a
semantic
question
of
of
telemetry
like
how
do
we
want
to
structure
the
native
spaces
that
it
makes
sense
to
Telemetry
consumers
right.
B
D
B
D
I
think
we're
already
two
minutes
over.
So
not
they
want
to
cut
this
off,
but
they
have
to
go,
and
we
can
continue
that
next
time
we're
offline
but
I
think
it's
it's
most
your
question.
What
makes
intuitive
sense
to
the
user
of
the
system,
and
in
that
regard,
you
agree.
D
So
thanks
everybody
for
today,
I
will
try
to
capture
this.
Our
discussion
in,
like
short,
summary
in
the
pr
comments
and
then
maybe
we
can
continue
offline
or
otherwise
next
week,
okay
or
or
by
the
way.
Next
week
is
Thanksgiving,
so
I
think
we
will
see
each
other
in
in
two
weeks,
because
I
cannot
come
next
week.
Probably
everybody
in
the
states
will
not
be
here
next
week,
so
I
guess
it
should.
We
should
cancel
next
weekend.
D
I
will
I
will
put
it
into
chat
in
in
the
slack
and
and
let's
see
what
we
preserve
for
me.
Theoretically,
other
days
would
work,
but
I
know
other
people
are
off
the
whole
week,
so
I
will
put
it
in
the
into
slacking.
People
can
just
give
thumbs
up
thumbs
down,
but
what
they
want
to
do
and
then
let's
go
from
there.