►
From YouTube: CDEvents Working Group (EMEA/AMERICAS) - August 8, 2023
Description
For more Continuous Delivery Foundation content, check out our blog: https://cd.foundation/blog/
A
C
B
I
hope
you
had
a
good
holiday
yeah.
C
D
C
B
I'll
be
off
until
the
beginning
of
September,
September,
okay,
so
I
be
back
for
one
day
on
the
17th
of
August
just
check
in
to
see.
If
there
is
anything
urgent,
I'll
be
up
again.
D
B
Okay,
yeah.
Yes,
it's
pretty
fast.
It's
bedtime
to
get
started
so
welcome
everyone
to
the
events
working
group
today.
My
name
is
Andrea
fritolay
I'm,
with
IBM
I,
put
the
link
to
the
notes
in
the
chat
feel
free
to
sign
yourself
in.
If
you
would
like
to
yeah
so
on
the
agenda
today,
I've
got
only
a
couple
of
items:
first,
it's
Oktoberfest
and
then
connecting
events
which
is
kind
of
the
main
item
you're
working
on
on
the
specification.
B
C
D
C
C
D
D
F
B
All
right,
so
the
first
thing
I
just
wanted
to
bring
it
up.
Hopefully
it's
just
a
quick
one,
but
so
we
discussed
Octoberfest
2023
that
he
brought
it
up
in
the
TLC
meeting.
B
So
and
Roxanne
would
like
to
know
by
the
end
of
August
which
project
applied
to
participate,
and
hopefully
you
have
like
a
blog
post
and
live
and
to
be
sent
to
the
CDF
by
September
29th.
So
last
year
we
did
participate.
We
did
a
blog
post
on
while
we
set
up
like
a
GitHub
issue,
and
that
was
what
we
published.
So
it
can
be
the
same
or
it
can
be
a
blog
post
and
some
Vlog
that
we
want,
and
then
we
need
a
project
contact
person.
B
That's
volunteering
to
be
like
the
point
of
contact
towards
CDF
for
arctoba
Fest,
so
yeah
put
your
link
to
Octoberfest
22
from
the
CDF
website
yeah.
So,
ideally,
the
list
of
participating
project
at
least
should
be
finalized
by
the
next
TLC
meeting.
You
know
so
August
15th,
so
I
wanted
to
to
bring
it
up.
I!
Think!
Last
year
we
did
participate.
We
had
a
little
bit
of
PRS,
a
few
PRS
happened
and
I
think
see
the
events.
B
Sorry
Oktoberfest
records
a
little
bit
of
initial
investment,
but
not
too
much
and
I
think
this
year
we
have
even
more
projects
and
things
that
where
people
could
contribute
to
and
I
think
the
more
we
best
invest.
The
better
is
for
the
return
so
last
year
with
Jenkins,
something
like
yeah,
so
they
and
where
is
it
yeah
like
166
PRS,
so
I'm
not
saying
that
the
City
events
we
we're
going
to
get
to
that
number,
but
already
last
year,
I
think
we
had
a
few.
B
So
maybe
if
we
keep
the
momentum
and
every
every
year
participate,
we
can
get
more
and
more
contribution
and
it
requires
a
little
bit
of
extra
review
bandwidth
and
maybe
the
contributor
or
not
like
the
occasional
contributor
but
still
I,
think
it's
beneficial
for
the
project.
B
We
need
to
write
a
blog
post-
oh
sorry,
not
technical
test.
So
this
is
a
copy
based
issue.
B
F
I
think
we
should
participate
as
well
and
I'm
happy
to
write
the
blog
post
for
it
sometimes
like
when
I
do
the
artillius
blog
post
I'll
list
specific
in
the
blog
post
office,
so
people
just
literally,
can
click
on
it
and
go
from
there.
I,
don't
think
we
can
I,
don't
think
we'll
be
there
unless
somebody
could
put
together
some
hacktoberfest
pull
requests
but
I'm
happy
to
do
that.
F
E
Yeah,
that's
pretty
pretty
big
if
they're
willing
to
contribute
a
proposal
and
then
kind
of
go
through
the
design.
I'd
be
probably
more
inclined
for
something
like
that,
but
especially
with
like
security.
That's
really!
You
know
you
have
to
just
be
careful.
So
you
know
you
just
don't
want
someone
coming
in
and
creating
a
PR
with
you
know,
saying:
oh
here's,
my
security
design
right
without
careful
considerations,
so
so
I
think
yeah
for
other
features.
E
We
can
definitely
lean
towards
you
know
doing
like
I'll,
send
you,
like
maybe
code
generations
for
the
sdks,
but
security
I.
Think
it's
a
little
a
little
large.
C
Yeah
I
think
I
tend
to
agree,
I
think.
Well.
Obviously
it
would
be
good
to
have
some
input
if
anyone
out
there
is
is
available
to
provide
ideas
for
security,
related
events
or
PLC
and
events
that
would
be
great,
but
I
think
also
that
October
1st
the
issues
should
be
such
kind
of
issues
that
could
easily
be
reviewed
by
one
or
two
persons
and
then
just
merged.
C
F
So
I'm
going
to
be
gone,
the
last
two
weeks
of
September.
So
if
we,
if
I'm
happy
to
write
the
blog,
we
just
need
to
decide
if
we
want
to
list
specific
issues
in
the
blog
so
or
how
you're
going
to
tag
them
and.
D
F
E
Yeah
I
think
you
know
having
so
generally
how
I've
seen
hacktoberfest
they
always
like
provide
some.
You
know
some
examples
that
people
can
solve.
I
think
we
can
definitely
come
up
with
a
list
like
I
said
like
a
big
one.
E
For
me,
for
the
sdks
is,
is
code
generation
and
modeling
like
language,
modeling
I
feel
like
we're
at
a
point
now
where
we
we
can
really
benefit
from
that,
and
they
could
even
start
with
just
modeling
a
small
portion
of
the
SDK
right
like
so
it
doesn't
need
to
be
the
whole
thing,
but
just
start
start
small
I
think
would
be
a
very
good
task
and
then,
of
course,
like
documentations,
always
always
good
as
well,
and
then
another
thing
that
I
thought
I
think
that
would
be
a
huge
another.
E
Huge
win
is
potential
abstraction
layers
on
top
of
the
SDK,
because
right
now
the
sdks
are
very
low
level.
So
having
things
like,
you
know,
hooks,
you
know,
custom
serializers,
deserializers,
things
of
that
would
would
go
a
very
long
way
of
people
adopting
you
know
because
right
now,
if
you
want
to
adopt
see
the
event,
you
have
to
write
all
this
custom
code
to
kind
of
get
it
bootstrapped
and
working.
E
F
It
had
been
I
think
adoption
is
such
an
important
Topic
in
this
area,
and
it
goes
beyond
us
actually
adoption
of
a
because
I'm
I
do
participate
a
lot
in
the
open,
SS,
open,
ssf
security,
tooling
discussions
and
part
of
the
problem
with
the
security
tooling
is
nobody
wants
to
update
their
their
workflow
files
to
add
one
tool
at
a
time?
So
we
do
have
an
opportunity
in
terms
of
disrupting
the
CD
Pipeline
with
CD
events
and
I.
E
Yeah
yeah,
I,
I,
agree,
I,
think
it's
that's
kind
of
like
the
future
of
how
I
see
the
sdks
working,
at
least
in
my
mind,
but,
like
I
said
we
don't
have
to
be
the
ones
who
write
it.
If
someone
is
willing
to
like
at
least
start
that
process,
you
know
where
they
make
some
easier
abstractions
and
then
we
just
kind
of
build
on
top
of
that
and
kind
of
keep
that
ball
rolling
would
be
really
really
nice
to
see.
That
would
be
a
huge
win
for
me
for
hacktoberfest.
B
Yeah
I
think
it
would
be
ideal
to
have
like
very.
We
could
have
at
least
a
combination
of,
like
very
small,
very
targeted
issues
for
beginners
that
want
to
just
solve
a
small
thing,
and
then
we
can
have
some
larger
ones
like
in
the
SDK,
improve
or
add
to
the
consideration.
Maybe
you
could
expand
benefit
on
the
modeling,
but
you
mean
if
you
want
to
create
an
issue
about
that.
All.
B
D
B
A
B
Anyway,
we
have
some
some
ideas
on
how
we
could
further
automated
generation
of
the
documentation,
for
instance,
so
we
get
people
looking
into
that
yeah.
So
one
thing
we
have
as
the
case,
but
we
don't
have
a
CLI,
so
maybe
building
a
CLI
out
of
one
of
the
sdks
could
also
be
an
option,
but.
D
B
It
could
be
I
mean
the
it
can
also
generation
of
code.
The
SDK
generation
like
for
go
is
done.
Programmatically
go
okay,
but
having
a
CLI
I
think
it's
very
handy.
If
your
buildings,
for
instance
some
adapter
and
you
want
to
have
some
easy
way
to
or
if
you
want
to
send
test
events,
for
instance,
try
things
out
having
an
SDK
CLI
that
allows
you
to
send
in
directly
I
think
it's
very
useful.
A
B
So
yeah,
so
if
folks
have
idea,
maybe
we
can
add
them
to
the
list
here
or
just
create
an
issue
and
start
attacking
them
with
Oktoberfest,
but
I
think
we
have
a
consensus
that
we
want
to
participate
thanks
again,
Tracy
for
volunteering,
for
the
writing,
a
blog
post,
yeah.
F
Just
keep
in
mind
that
I
will
be
on
vacation
for
two
weeks,
so
I
will
need
to
get
it
done
sometime
after
Labor
Day
we'll
have
to
get
it
done
early.
B
Nice
anyone
wants
to
to
be
like
the
point
of
contact
towards
the
CDF
for
Oktoberfest
kind
of.
F
B
F
Okay,
Roxanna!
Let
her
know
to
keep
me
posted,
but
I'm
happy
to
do
that.
C
F
Think
we
tagged
him
with
hacktoberfest
for
any
issue.
That
was
in
fact
that's
how
they
had
to
be
Tagged.
So
if
we
get
in
there
and
tag
them
and
then
I
can
I
can
go
through
and
in
the
blog
I
can
list
some
of
the
specific
ones
and
I
tried
it.
I've
I've
copied
how
Jenkins
does
it
so
I
haven't
come
up
with
something
new,
so
I
do
exactly
how
Jacob's
writes
theirs
and
it
when
you
put
the
when
you
put
a
handful
of
the
the
issues
out
there,
it
does
tend
to
help.
D
A
B
I
mean
we
had
ideas
of
sdks
that
we
don't
have
today.
I
mean
those
are
not
small
ones,
but
if
anyone
wants
to
like
a
bigger
project
or
again
kick-started
at
least
so
yeah,
that's
something
and
in
in
this
direction.
B
Maybe
we
have
one
outstanding
issue
that
is
assigned
to
me:
I
can
work
on
that
to
Define
what
are
kind
of
the
requirement
for
an
SDK,
so
I
can
start
graphing
that,
and
so
we
can
use
that
as
like
guidelines
for
people
that
might
want
to
contribute
to
this,
but
yeah.
It
would
be
good
to
have
like
some
smaller
ones
as
well.
F
Yeah
I'm
putting
this
to
work
on
this
on
my
calendar
for
September
the
6th.
F
E
And
then
on
Andrea
did
is
the
Java
SDK
up
to
date.
I
remember:
you
said
that
it
was
kind
of
lagging
behind
last
time.
Is
that
something
we
can
also
add?
Maybe
you
know
sync
it
up
to
latest
or
if
you
want
to
call
it
that.
B
Yeah,
so
the
JavaScript
well
jalander,
maybe
can
talk
better
to
to
that,
but
so
we
just
made
the
one
0
to
1.012
release,
which
is
up
to
date.
With
that
version
of
the
specification
and
jalander
has
been
working
on
the
code
generation
and
once
that's
merged
it
hopefully
should
be
pretty
straightforward
and
to
to
make
it
zero.
Two
and
zero
free
release
calendar
sorry
I.
Maybe
you
want
to
to
add
to
that
the
latest
status
on
that,
oh.
A
Yeah,
that's
all
like
the
generator
code
isn't
pending
for
review,
so
once
that
is
merged,
so
we
will
have
another
PR
the
whole
PR
to
generate
different
events
yeah.
So
with
that,
like
we
can
go
to
the
latest
version
of,
like
you
said
yeah,
so
I'm
waiting
on
the
pr
to
review
for
the
latest
one.
So
that's
that's
the
first
step
to
go
to
the
another
versions.
Yeah
nice.
B
Do
you
think
there
are
some
sub
tasks
within
that
work
that
could
be
created
as
issues
for
Oktoberfest
or
is
it.
A
It
has
subtask
like
to
generate
other
events
on
the
same
line
once
this
PR
is
done
so
yeah,
probably
it'll
be
done
like
before
only
I
guess
like
because
the
changes
that
I've
done
is
in
progress,
I
mean
some
changes
are
in
progress
already
and
I
can
raise
a
PR
for
that,
so
it
it
may
not
go
till
October
October
yeah,
so
it
can
be
done
before
that
even
yeah.
Okay,.
D
B
Right
so
next
in
the
list
I
had
connecting
events,
does
it
make
sense
to
go
to
that
for
everyone.
E
Yeah
so
so
primarily,
I
think
we're
at
a
point
where
I'm
just
waiting
for
for
review
comments.
I've
addressed
all
of
Andrea's
feedback,
which
was
about
a
week
ago,
so
we're
at
a
good
point
where
the
spec
is
pretty
pretty
finalized
from
from
my
end,
I
mean,
of
course
you
know.
If
we
want
to
change
things,
then
of
course,
but
but
I
think
we
have
a
pretty
good
I
I
feel
very
confident
in
in
the
design.
E
Now,
where
I
feel
like
this,
could
this
could
work
really
really
well
I
added
the
fields
that
you
wanted
in
the
the
context
there
Andrea.
D
E
I
did
mention
that
the
sdks
could
pull
those
down
from
the
headers
which
so
we're
just
not
you
know,
send
duplicate
information
through
the
over
the
wire
but
but
yeah,
and
so
I
started
thinking
about
it,
some
more
with
so
I
removed
the
so
originally
had
the
links.
Also
a
lynx
field
added
as
well,
but
like
the
parent
field,
but
I
think
because
I
don't
know
about
the
use
cases
of
how
people
are
going
to
be
using
CD
events.
E
I
just
don't
have
enough
information
to
make
the
correct
Judgment
of
including
a
parent
a
field
just
yet.
My
idea
was
that
we
could
release
or
let's
say
we
release
this
version,
but
if
we
get
feedback,
people
saying
oh
every
time,
I
get
a
CD
event.
I
have
to
query
the
parent
ID
or
the
global
ID.
To
get
some
sort
of
information.
We
can
use
that
data
to
ex
you
know,
expand
the
you
know
the
proposal
right
to
include
like
whatever
necessary
use
cases.
You
know
if
someone's
like.
E
Then
we
can
include
that
in
as
a
new
separate
field,
but
I
think
starting
simple
and
small
and
getting
the
connection
portion
right
first
before
I
start
thinking
about
like
originally
I
was
thinking
about
like
Optimal,
like
you
know,
trying
to
optimize,
or
you
know,
trying
to
send
what
is
necessary
for
a
consumer,
but
since
the
consumer
can
just
query
that
anyways
and
then
do
what
they
will
I
felt
like
you
know,
this
was
the
better
approach,
so
that
was
kind
of
like
the
thought
process
there
and
Emil
since
you've
been
Missing,
yeah
I
added
these
two
headers,
which
is
the
global
IDs
and
the
parent
IDs,
which
would
be
it
follows,
follows
the
RFC
which
I
linked
somewhere,
which
you
know
it's
comma,
separated
the
typical
HP
header,
spec
and
and
yeah,
and
then
also
a
meal.
E
I
have
a
section
towards
the
bottom
that
I
updated
that
discusses
tracing.
So
it
goes
over
like
why
tracing's,
probably
not
the
best
approach
for
for
for
links,
so
so
yeah,
so
I
kind
of
go
over
it.
So
I'll
kind
of
give
you
the
the
rough
outline.
So
basically
spans
are.
You
know
work
spin
is
a
superset
of
of
a
link,
so
all
right,
I
think
I.
Have
that
reverse,
so
I
should
actually
fix
that
it
should
be.
E
A
link
is
a
superset
of
of
a
span,
while
the
formats
don't
overlap.
I
s,
you
know
I
illustrate
that
a
span
has
a
lot
of
information,
so
I
give
you
the
the
link
or
the
example
span
of
of
open
Telemetry
standard.
E
So
if
you
scroll
down
a
little
bit,
that's
all
of
the
necessary
fields
that
are
required.
Most
of
them
are
required,
but
but
some
of
them
are
not
like
Flavor,
for
instance,
is
the
optional
feel,
but
the
reason
why
this
is
important
that
I
want
to
highlight
here
is:
if
you
have
something
that
like
HTTP
method
is
empty
or
HP
server
route
is
empty.
Like
these
fields
are
missing,
some
collectors,
Like,
Jaeger
or
x-ray-
won't
show
it
will
drop
that
span.
E
So
if
we
do
adopt
open
Telemetry,
we
would
have
to
basically
be
forced
to
use
their
semantics,
which
is
a
little
concerning,
and
people
might
not
know
like
when
they're
using
open
Telemetry
with
CD
events.
You
know
what
spans
are
required
and
whatnot.
E
Of
course,
we
should
probably
hide
that,
but
but,
like
I
said
that
you
know,
if
someone's
manually
modifying
these
bands,
they
can
make,
they
can
put
themselves
in
a
world
of
hurt
if
they,
if
they
don't
understand
what
what
is
required
and
what
is
not
and
what's
even
more
on
the
pain
is
x-ray
has
different
required
Fields
than
than
Jaeger
and
by
different
I
should
say
it
just
has
more
required
Fields,
not
not
different.
It
just
has
more
required
Fields.
E
So
if
you
go
down
a
little
bit,
I
kind
of
give
some
more
details
on
the
how
context
propagation
is
is
handled
and
it
kind
of
goes
over.
Like
you
know,
like
the
complications,
you
know
like
how
it
passes
it
with,
like
you
know,
headers
and
so
on,
and
it
kind
of
goes
over
with
the
the
missing.
E
If
you're
missing
a
status
code,
for
example,
that
span
just
gets
dropped
in
sorry,
it
gets
dropped
in
the
in
the
open,
AWS
open,
Telemetry
collector,
depending
on
the
collector
you
use,
it
might
not
be
dropped.
So
it's
not
even
uniform
across
the
tooling's,
not
uniform.
So
it's
really
hard
to
know
what
what
might
not
what
might
or
might
not
be
needed
so
so
yeah.
E
So
that's
kind
of
the
issue
there
and
then
I
kind
of
if
you
scroll
down
a
little
bit
some
more
there
yeah
so
I
said
based
on
the
number
of
complications.
It
kind
of
illustrates
like
what
we
would
need
to
do
to
support
something
like
open,
Telemetry
and
the
work
there
is
not
small
I
would
say
it
might
be
roughly
the
same
as
doing
anything
else.
E
Honestly,
the
only
benefit
that
we
get
here
is
that
we
get
to
you
utilize,
a
collector,
but
the
collector
is
not
the
the
main
concern.
E
The
Collector
is
actually
probably
the
more
easiest
pieces
of
software
here
out
of
the
whole
thing,
but
the
issue
is
that,
since
the
collectors
are
so
different
from
one
collector
to
another,
depending
on
the
the
the
the
tracing
software
that
you
use,
that
it
can,
like
you
said,
you
know
within
dropping
spans
and
whatnot
could
lead
to
more
problems
than
it
than
it
actually
helps.
E
And
then
we
would
also
need
to
write
a
custom
exporter
for
for
for
these
collectors,
which
it
would
be
basically
writing
a
collector
in
the
first
place.
So,
like
I,
said
a
lot
of
the
code
that
we'd
be
writing
would
like
it.
It's
based.
It's
almost
The
Identical
amount
of
work
with
the
one
caveat
of
writing
a
basically
the
server
of
like
ingesting
the
spans
or
the
tracings
bands,
so
so
yeah.
E
So
with
that
said,
it
has
a
lot
of
issues
with
with
with
the
collectors
with
the
sdks,
with
the
tooling
and
and
I
feel,
because
of
that,
you
know
that
I
think
it's
better
to
go
with
our
own.
Simplified
version
well
simplified,
as
in
it's
simple,
because
it
only
supports
what
we
need
it
to
support
right.
E
So
that's
kind
of
like
where,
where
I'm
standing
at
currently
at
the
at
the
decision,
so
I
know
you're
not
going
to
be
able
to,
you
know,
get
the
full
picture
just
yet
Emil
because
you're
still
reading
this.
But
you
know
if
you
could
take
some
time-
and
you
know
you
know
address
or
you
know
whatever
comments
you
have-
that
that
would
be
really
really
useful
there
and
I
try
to
outline
as
much
as
I
could.
E
So,
if
something
doesn't
isn't
clear,
please
let
me
know
and
I
can
expand
on
it
kind
of
you
know
like,
for
instance,
if
I
say
hooks
to
potentially
separate
out
normal
traces
from
CD
events.
E
If
you
need
me
to
expand
on
that
because
the
issue
there
is
when
you
include
a
tracing
Library,
there's
no
concept
of
like
expand
like
expanding
separating
separating
things
out
like
you
need
a
separate,
a
separate
plug-in
to
handle
the
separation.
If
you
will
so
that's
how
Zipkin
works,
it's
how
B3
propagation
works,
so
we
so
we
at
Apple
we
use
Zipkin,
but
that
is
a
plug-in
in
in
the
brave
Library.
E
So
so
yeah
so
like
I,
said
that's
what
I
meant
by
like
we'd
just
be
just
writing
plugins
as
opposed
to
writing
a
full
library
but,
like
I
said
like,
since
this
is
going
to
be
a
more
simplified
version,
the
library
shouldn't
be
as
complex
but
but
yeah
curious
to
hear
your
thoughts.
Yeah.
C
I
think
you
make
very
much
sense
there
and
I.
Don't
think
we
should
have
any
definitions
in
City
events
that
are
specific
to
Jager
or
Zipkin
or
any
other
x-ray
or
anything
I.
Think
when
I,
when
I
brought
up
the
idea
of
reusing
the
trace
context,
definition
from
from
token
telemetry
here,
I
think
that
was
more
like.
We
should
use
the
same
names
for
things
that
are
called
something
specific
in
in
the
Telemetry,
for
example,
is
it
apparent?
Is
it
a
global?
Is
it
what
is
it
called.
E
C
E
So
the
names
Global
ID
and
parent
IDs
are
used
in
open
Telemetry.
Actually,
this
is
where
like
I
kind
of
came
up
with
these
names
is
by
taking
them
from
open
Telemetry,
because
I
have
a
lot
of
familiarity
with
that.
So
yeah
yeah,
I
I,
think
that
is
a
good
idea
to
make
sure
that
we
have.
E
At
least
you
know
the
same
verbiage
and
same
you
know
semantics
there
to
make
sure
that
you
know
people
that
are
coming
from
one
piece
of
technology
to
another:
have
some
sort
of
idea
or
clue
to
what
we're
talking
about
so
yeah
but
yeah.
The
like
I,
said
you
know,
please,
please
read
that
and
kind
of
get
some
more
input
there
and
if
you
need
me,
give
you
like
I,
have
pictures
of
like
traces
being
dropped.
E
So
if
you
want
to
see
that,
like
you
know
missing
like
one
feel
like
what
that
looks
like,
because,
basically
you
have
this
whole
graph
and
then
you
have
this
blank
section
of
of
nothing
and
then
they
don't
know
how
things
are
connected
so
that
it
kind
of
gets
lost.
You
get
two
separate
choices,
almost
so
no.
C
Not
I
think
what
I'm
expecting
it's
just
that
we
should
reuse
the
same
Concepts
and
we
yes,
yes,
the
sub
structures,
maybe
reuse
them,
whatever
that's
suitable,
yeah,
the
names
themselves
only
I'm
a
bit
concerned.
Now,
when
we
talk
about,
we
say
this
is
the
links.md
and
we
talk
about
introducing
links
to
see
the
events,
but
what
we
actually
do
is
just
a
global
ID.
Maybe
apparently,
if
we
include
that
to
you,
it's
just
a
global
ID
in
in
what
way
is
that
really
linking
anything
it
to
me?
E
No,
no,
it
is
going
to
be
linking
so
this
just
introduces
the
two
fields
that
are
going
to
be
present
in
the
in
the
the
payload.
But
if
you
can
scroll,
I,
don't
know
if
it's
up
or
down
it
goes
over
to
storage
and
oh
wait
no
to
go
up
to
the
image.
Actually,
the
image
gives
you
a
better
idea
of
like
what's
happening.
E
It's
at
the
very
top
of
the
image.
I
haven't
clicked
that.
E
Have
view
file
so
yeah,
so
this
is
what
we'd
be
sending
so
basically,
when
you're
sending
a
when
you're
using
the
sdks,
they
would
automatically
send
these
links
for
you.
So
when
you
make
a
call
like
a
CD
event
like
let's
say
you
make
like
a
trigger
cost
or
some
some
sort
of
event,
it
would
collect
all
these
links
or
all
these
calls
you
are
making
and
then
submit
them
to
to
this
link
service.
E
But
those
two
Fields
would
just
kind
of
give
you
an
idea
of
the
person,
that's
consuming
it,
where
it's
coming
from
and
how
to
query
it
if
they
choose
so
that's
kind
of
those
are
the
two
Fields.
So
there's
two
parts
to
this
to
this
proposal.
The
first
part
is
what
is
changing
in
the
spec
and
then
the
second
part
is:
how
do
we
send
the
necessary
information?
The
links
in
this
case,
like
the
you
know,
give
it
some
meaning
of
how
things
are
connected
to
some.
E
You
know
in
this
case,
I
call
it
the
link
service,
but
it
could
also
be
a
part
of
the
event,
bus
or
whatever.
We
want
to
call
it
so
yeah,
so
that
I
think
that
answers
a
question
in
the
middle
does.
Does
it.
E
E
I'm
just
gonna
say,
like
you
know,
because
when
I,
when
I
first
discussed
it
because
I
don't
want
to
regurgitate
the
same
thing
every
single
time,
you
know
when
I
went
over
the
the
the
different
types
of
links.
You
know
it's
the
kind
of
section
by
section,
but
I
wanted
to
go
over
the
the
tracing
part,
because
that
was
also
updated
since
you
had
less
left
and
and
then
the
the
two,
the
headers
and
and
whatnot,
but
yeah
yeah.
E
So
if
you
just
read,
you
know,
read
the
proposal
and
kind
of
go
through
what
your
thoughts
are,
but
yeah
yeah,
it's
it's!
You
know
like
I
said
it's
it's
doing
quite
you
know
like
it's
changing
it's
changing
the
spec
as
well,
as
you
know,
defining
how
we're
persisting
the
relationships
between
between
each
CD
event.
C
D
C
E
Yeah
well,
originally
I
was
going.
You
know
with
what
we
talked
about
with
like
the
links,
but
I
wanted
to
start
with
a
more
simple
approach
for
like
I
feel
like
this.
This
it's
a
simplified
version
of
what
we
talked
about
honestly
and
I
feel
like
this
simplified
version
handles
most,
if
not
all,
use
cases.
So
that's
why
I
went
with
this
approach
because,
like
I
said,
simple
I
was
a
I'm,
a
huge
believer
in
Simplicity,
but
that's
not
to
say
I
could
have
missed
something
I
mean
I'm
I'm.
E
You
know,
that's
why
you
know
I
want
people
to
review
this.
So
if
I
do
miss
something
and
we
need
to
change
something
or
add
something
or
remove
something.
You
know
please,
please
let
me
know,
but
I
I
think
I
think
the
links
the
format
with
the
two
and
the
from
and
the
group
handles
should
be
able
to
handle
what
you
guys
are
doing
at
Erickson.
E
E
Okay,
yeah
no
worries
and
then
also
to
I,
wanted
to
bring
up
something.
That's
not
related
to
this,
but
Andrea
I
am
going
to
create
a
few
PRS
about
the
the
you
know,
GitHub
issues
you
know
introducing
the
new
Fields,
like
you
know,
top
level
description
and
things
like
that,
so
I'll
create
I'll,
create
those
PR's
today,
I'll
try
to
create
at
least
one
or
two
today
and
then
and
then
try
to
get
the
get
them
all
done.
B
Worries
thanks,
but
before
we
move
away
from
from
the
connecting
events,
but
I
had
some
some
question
as
well,
so
sure.
D
B
Just
wanted
to
understand:
well,
one
very
simple,
I
think
a
the
parent
IDs.
It's
that's,
potentially
an
array
right,
yeah.
E
Yeah,
so
it
follows
the
headers
RFC,
which
are
any
any
header.
It
will
technically
all
headers
are
erased.
Yeah.
B
E
Oh
God
I
got
it
got
yeah
because
my
assumption
would
be.
However,
the
sdks
are
consuming
this.
This
would
either
be
a
comma
separated
string,
but
my
the
sdks,
however,
would
probably
parse
that
and
make
that
an
array
right,
but
this
would
be
probably
a
a
comma
separate
string
like
well
we'll
just
be
it
would
be
a
header,
that's
comma,
separated
right.
So.
B
In
in
the
header,
yes,
but
I
think
from
us
back
point
of
view,
we
should
really
stick
with
the
the
Json
schemas
and
what
is
in
there
I
mean.
We
can
then
say
what
we
want
in
the
sdks
or
I
mean
the
the.
The
fact
is
that
I
mean
CD
events.
B
We
have
a
a
binding
for
cloud
events,
but
Cloud
events
also
is
not
necessarily
transported
on
http,
so
I
think
defining
it's
it's
a
bit
confusing
for
me
to
start
with
the
HTTP
header
as
part
of
the
spec,
but
I
mean,
as
I
said,
I.
Think
in
my
previous
comment,
I
think
we
can
say
if
some
non-city
event
system
wants
to
send
HTTP
headers
to
have
similar
or
consistent
information.
B
So
we
can
have
like
Cloud
event,
extensions
and
those
are
in
the
cloud
events
binding,
then
they're
rendered
as
HTTP
headers,
but
the
format
could
couldn't
be
like
x,
dash
CD
events,
because
if
you
send
that
through
a
c
Cloud
events
router,
it
would
drop
those
headers
so
anything
that
any
header
that
is
not
known
by
Cloud
events,
it
will
be
dropped,
so
I
I
think
I
investigated
this.
E
E
Okay,
yeah,
that's
that's
perfect!
That's
perfectly
fine.
I
just
chose
any
arbitrary
because
I
didn't
know
the
restrictions
for
for
cloud
events.
E
Yeah,
let
me
think
about
that,
but
on
on
top
of
that,
though,
we
should
make
headers
a
part
of
the
spec.
If
they're
not
you
know,
nine
like
I,
don't
understand
why
headers
wouldn't
be
because
a
lot
of
times
people
are
going
to
be
using
HTTP
or
grpc,
which
is
just
a
layer
on
top
of
HTTP
right.
C
I
mean
not
always
at
all,
I
mean
we
as
rabbit
them.
Cubital
generics
have
those
others.
For
example,
yeah.
E
Yeah
and
and
and
that's
fine-
and
you
know
you
might
be,
you
know,
one
of
the
different
use
kits
I
would
say
like
a
good
like
well.
No,
because
racing
tracing
is
a
good
example.
They
all
use
headers.
E
Yeah
yeah,
but
but
that's
fine
though
right
because
like
if
you
can
have
tracing
that
has
headers
it
could
still
work.
You
know,
oh,
what
you're
saying
for
the
message:
bus
when
you
send
it
right
is
that
what
you're
saying
yeah.
C
E
Okay,
okay,
yeah
and-
and
that's
you
know,
that's
fine.
You
know
that
could
be
something
you
know
if
it's
not
HP
supported,
you
know
it
could
be
then,
just
in
in
the
body
like
how
it
already
is,
but
we
want
to
also
support
HTTP
as
well,
because,
like
I
said,
that's
what
tracing
does
and
that's
how
Pro
that's
how
propagation
works
as
well.
E
You
know
like
if
some,
if
you're
sending
a
for
instance,
if
you're
sending
an
event,
you
know
to
some
service
that
doesn't
have
that
doesn't
have
support
for
CD
events.
You
know
your
that
body
the
this
all
this
context,
all
that
information.
That's
just
going
to
be
lost
right,
like
this
Global
ID
parent
ID,
like
that's
just
gonna,
be
that's
just
gonna
be
gone,
you
know,
but
if
they
have
a
header
they
can
at
least
you
know,
pass
the
headers
with
with
whatever
payload
that
they
are.
They.
E
E
It's
a
lot
easier
to
just
whitelist
two
headers
than
it
is
to
change
a
model.
So
that's
why
I
think
it
should
still
be
maybe
part
of
maybe
not
really
part
of
the
spec,
but
maybe
talk
about
how
to
handle
the
passing
of
or
propagating
linking
between
Events.
Maybe
that's
a
better
way
of
pro
approaching
it.
But
but
I
do
want
to
talk
about
you
know,
maybe
we
could
say
like
instead
of
new
headers,
we
could
call
it
new
Fields,
slash
propagation
or
something
of
that
nature.
E
If
that
helps,
but
but
yeah
I
think
we
still
want
to
have
some
description
of
you
know
if
you
wanna,
if
you
support
HTTP
and
you-
and
this
is
what
you're
using
you-
can
definitely
use
these.
These
two
headers
and
the
sdks
will
pull
those
down
and
then
yeah
and
then
continue
to
use
them
if
they
exist.
B
Yeah
I
think
the
the
only
thing
is
that
we
want.
We
want
City
events
to
be
Portable,
On,
Top
different
type
of
transport
right.
So
that's
that's
why
it
starts
from
the
context
and
subject:
that's
that
you're
there
and
in
there
you
can
have
these
new
Fields
like
the
global
ID
and
the
list
of
parentheses,
and
then
you
have
still
part
of
this
pack,
but
the
the
kind
of
The
Binding
type
of
document
where
you
say
Well
when
I'm
transporting
this
city
event
on
top
of
HTTP.
These
two
Fields
should
actually
be
rendered
yeah.
E
I
definitely
agree
but
I,
it's
weird
to
me
that
maybe
because
Robert
mq
is
old,
that
they
have
no
way
of
supporting
headers
or
something
of
that
nature
because,
like
tracing,
if
you
have
a
black
box
even
on
you
know
like
the
greatest
thing
about
tracing,
is
that
you
can?
E
You
know
you
can
trace
whatever
you
know
like
whatever
service
but
propagation
is
done
through
headers
I'm
sure
there's,
probably
some
plugins
that
allow
for
propagating
it
without
headers,
but
it's
probably
converting
it
to
headers
later
so
it
might
need
to
be
like
a
rabbit.
E
M
Cube
plug-in
that
that
does
the
kind
of
the
same
thing
I
would
have
I
would
have
to
look
but
yeah,
but
yeah
like
like
I,
said,
though
header
like
HTTP
and
HTTP
2
like
if
we
were
back
10
15
years
ago,
I
would
say
yeah
we
should
probably
not
include
headers
in
in
in
the
in
the
spec,
but
hb2
is
so
powerful
that
I
I
think
like
I,
don't
like
I
said
like
I'm
really
like
it
really
shocked
me
that
rabbit
and
Q
doesn't
support
it.
I'm
actually
gonna.
E
Look
that
up
because
it's
kind
of
weird
but
but
yeah
but
I,
think
I.
Think
I
can
definitely
add
those
points,
though,
and
make
it
more
protocol
agnostic,
but
I
I,
don't
know
like
what
other
Protocols
are
there
that
you
guys
want
to
support.
B
Well,
I
mean
you
could
have
one
of
the
things
that
we
are
considering
is
working
with
the
open,
Telemetry
folks
to
support,
sending
like
a
Json
City
event
as
a
Json
body
into
a
like
open,
Telemetry
type
of
message,
but
that's
that's
still
not
defined,
but
there
is
a
proposal
on
open
Telemetry
side,
but
even
with
Cloud
events
that
we
have
today
Cloud
events,
they
have
multiple
type
of
transported.
B
E
It
got
it
right:
okay,
yeah
I,
see
because
mqtt
is
quite
old
and
okay,
but
yeah
people
are
using
that.
Okay
yeah.
Let
me
let
me
think
about,
and
it
sounds
like
a
bill.
It
sounds
like
you
guys
are
using
mqtt
or
or.
E
Oh
yeah,
no,
no
I'm,
just
wondering
yeah
because,
like
because
rabbit
mq,
I
think
by
default
uses
mqtt,
but
it
could
be
wrong.
E
C
D
E
Okay,
okay,
then,
how
yeah
then
rather
thanq
can't
work
with
tracing
then
unless
well,
they
can,
because
it
has
HP
support
with
a
plug-in,
though
so
or
not,
with
a
plug-in.
Oh
yeah.
It
is
plug-in
okay,
so
yeah,
so
you
can
use
tracing
with
that
rabbitmq
except
you
would
have
to
use
a
plug-in
for
that.
C
E
I
think
Kafka
and
websockets
are
all
based
on
HTTP.
Aren't
they.
E
Yeah
yeah
it's
based
on
each
yeah
that
these
are
all
like.
A
lot
of
these
are
subsets
of
HP
like
protobuf,
is
HTTP
2.
web
hooks.
Those
are
web,
that's
HP,
XML,
that's
HTTP,
Json,
that's
HP!
Hp
is
HTTP
websocks
also
HTTP,
so,
like
half
of
these
are
already
supported
by
H
they're,
all
just
http.
D
C
Json
structures
look
like,
then
how
we
transport
it
and
how
how
it
can
be
filtered
or
routed
in
the
transport
layer.
That's
another
question
and
it's
a
question
about
the
binding
right
right.
The
content
of
the
event
should
be
our
primary
focus
and
then
I
think
what
Andrea
you
were
into
there,
that
parent
ID
in
the
Json
body
down
there
should
be
a
list.
Sorry
an
array
instead
of
a
string,
the
volume.
C
E
E
E
However,
you're
sending
this
data
depends
on
your
bindings
and
then
I
can
mention,
for
example,
HTTP.
Would
these
would
be
headers
that
would
be
populated
in
the
Json
but
would
be
sent
as
headers
and
then
vice
versa.
I
can
include
like
mqtt
Kafka
and
then
we'll
still
be
headers,
but
just
a
different
ideas
would
that
work
that
would
at
least
make
it
agnostic
that.
E
Got
it
yeah
yeah
that
works
perfect,
okay,
I'll
I'll
update
that
to
make
this
more
agnostic,
and
then
that
should
handle
that
and
then
I'll
fix
that
to
be
an
array
as
well.
Yeah.
B
B
E
But
then,
okay,
I,
don't
know
enough
about
the
cloud
events
SDK
too
much
I'm
curious.
How
does
it
put
the
headers
back
into
Json
and
vice
versa,
I'm
guessing
it?
It
has
some
way
but
I'm,
just
kind
of
curious.
What
that
looks
like
okay,
yeah
I'll
do
a
little
bit
of
research
on
that
too,
to
kind
of
familiarize
myself
with
with
that
part
of
things.
D
B
E
E
You
know
I
have
an
idea
how
I
would
do
it,
because
you
know
I
have
a
lot
of
experience
with
sdks
I'm,
just
like
I
had
no
idea
that
that
that's
something
that
they
already
supported.
But
that's
that's
good
to
know
and
I
completely
forgot.
They
existed
to
be
honest.
I
got
a
cloud
of
it,
so
so
yeah.
B
All
right:
well,
we
are
almost
a
time
I
guess
we
can
take
that
the
rest
of
the
topics
for
a
carryover
for
the
next
meeting,
but
thanks
a
lot
for
for
the
presentation
on
this
and
then
for
the
discussion.
I
also
feel
like
we're
getting
close
to
being
ready
to
release
this.
So
that's
great
yeah.
E
E
So,
basically,
if
a
meal
has
okay
with
this
is
okay
with
the
structure,
I'll
go
ahead
and
and
add
the
the
Json
schema
to
the
pr
as
well
so
yeah
that
wasn't
a
question.
I
was
just
letting
you
know
what
what
my
plans
were.
C
Yeah
I
should
I
can't
guarantee
I
might
be
able
to
do
it
on
Thursday
tomorrow,
I
will
be
totally
busy,
but
on
Thursday
I
might
be
able
to
look
into
this
event.
So,
hopefully,
by
end
of
Thursday,
you
will
have
some
some
feedback
from
me
on
this
I.
E
Just
let
me
know
you
know
whenever
you
get
around
to
it
and
then
once
we
once
I
figure
out,
you
know
we're
at
a
more
stable
portion
of
things,
aren't
going
to
be
changing,
at
least
with
the
the
payload
side
of
things,
I'll
I'll,
add
the
the
Json
schema
and,
and
whatever
else
that's
left
on
on
the
to-do's.
For
that
PR.
F
So
guys
I
have
another
call
to
jump
on.
A
D
B
Yes,
that
was
kind
of
for
Target
date,
I
guess
the
main
beta
functionality
that
we're
aiming
to
get
in
there,
as
was
this
connecting
event
so
I,
don't
think
that
we'll
be
ready
for
August
the
30
first.
F
E
No
I
think
I
think
we're
good
and
good
to
have
you
back
Emil.
We
missed
you.
C
E
Yeah
yeah,
you
do
anything
fun
for
a
vacation
or
just
relax.
A
E
C
E
Yeah,
cool
cool
well
all
right!
Well,
thanks
thanks
everyone,
a
good
discussion
on
on
the
on
the
lynx
proposal,
I'll
make
those
changes
and
then
we'll
go
from
there.