►
From YouTube: CDEvents / SIG Events Vocabulary - Aug 9, 2022
Description
For more Continuous Delivery Foundation content, check out our blog: https://cd.foundation/blog/
A
Eric's
ascent
is
a
link.
You
have
send
it
it's
available.
C
A
C
C
I
don't
remember,
I
think
so,
and
they
an
email,
the
hackmd
notes
they
are
open
to
anyone
who's
registered
with,
like
a
github
account
right.
You
don't
need
any
special
permissions
to
be
able
to
edit
it.
C
B
Okay,
I
guess
it's
free
past,
so
it's
good
time
to
get
started,
welcome
everyone.
So
this
is
the
cd
event.
Working
group
today
is
august.
The
9th-
and
let
me
see
if
I
can
share
my
screen.
A
B
B
I
wanted
to
start
with,
so
this
meeting
is
recorded
so
that
everyone
knows-
and
I
set
up
some
automation
users
up
here
for
now
it's
at
least
with
my
personal
account,
but
basically
once
the
meeting
recording
is
complete,
it's
automatically
uploaded
into
youtube,
and
then
I
just
have
one
manual
step
left,
which
is
to
to
go
and
edit
into
the
playlist
so
that
the
recording
is
available.
Then
in
the
sync
events,
playlist
and
yeah.
So
the
first
three
is
the
python
sdk
demo.
B
D
Real
quick
can
I
I
can't
edit
and
add
myself,
is
that?
Is
there
a
reason
for
that
to
this
document?
You
have
account
yeah
like
found.
C
Yes,
so
I
have
invited
my
colleague
tarek
here
today
because
he
is
the
one
that
has
been
working
on
the
python
sdk
for
us
and
yeah.
I
think
tariq.
When
you're
ready
you
can.
Hopefully
you
can
take
over
the
screen
sharing.
If
not,
you
need
to
be
assigned
co-host
by
someone,
but
you
can
try
it
and
then
go
ahead
and
show
us
what
you
got.
B
C
A
A
A
As
you
might
know,
so
this
this
go
version,
it's
a
kind
of
a
cli
cmd
application
to
send
to
create
even
and
directly
send
it
from
from
the
terminal.
So
I
created
here
a
receiver.
This
is
just
just
for
testing.
Whenever
you
would
like
to
send
event
using
this
go
sdk
you,
you
can't
just
send
it
for
this
receiver,
so
I
control
this
receiver
and
send
one
on.
I
want
test
from
zago
sdk.
A
It's
just
calling
the
binary
give
it
which
kind
of
event
we'd
like
to
send
and
it
is
started
on
the
cover
of
metadata
and
we
when
we
click
it,
send
it,
and
we
have
the
receiver,
receive
the
data
here.
So
what
we,
what
we
was
looking
for
is
to
create
exactly
the
same
thing
with
kind
of
tweaking
for
visual,
but
using
but
using
bison,
but
which
we
just
created
the
same
sdk
but
using
voice.
A
So
what
we
have
here,
we
have
mainly
two
two
package,
one
one
as
a
cool
and
one
as
a
c
li.
The
core
packages
include
separated
objects
for
each
event,
so
we
have,
for
example,
branch
event.
We
have
artifactory
event,
we
have
build
event
and
environment
environment
event,
as
we
have
in
in
go
version.
A
We
have
for
each
event
kind
of
it's
kind
of
choiceable
or
you
know
it
represents
for
this
environment,
the
event
what's
happening,
it's
created
or
it's
modified
or
it's
deleted,
and
when
you
send
this
event
on
the
other
side,
the
receiver
will
receive
this
kind.
This
type
of
event,
it's
for
example,
start
version.
A
So
that's
exactly
what
we
have
here.
We
have
kind
of
object,
representation
for
each
event,
included
the
metadata
related
to
this,
even
for
so,
for
example,
for
the
environment.
We
have
id
and
name
and
review
for
the
build
we
have
id
and
name
on
the
artifactory
and
it's
kind
of
different
from
like
in
pipeline.
It's
a
very
different
idea,
and
name
and
state
and
url,
so
we
just
create
here
the
object
and
when
they
make
it
ready
to
be,
send
it
or
to
be
modified.
After
from
this
point,
we
have,
we
have.
A
To
also
receive
the
event,
so
what
we
have
here
is
we
just
create
the
event,
and
I
will
show
you
how
we
send
it
through
the
c
line,
but
we
we
have
also
kind
of
kind
of
vision
like
that.
We
can
also
from
the
receiver
side
that
you
can
receive
this
event
and
understand
this
even
like
this
kind
of
build
object
start,
but
this
is,
this
is
still
still
under
working
now.
So
it's
not
fully
done
so.
A
This
is
this,
this,
the
core
bracket,
the
corporate
or
the
code
for
the
package
and
the
other
package
is
the
cli
which
is
actually
which
is
first
of
all,
is
the
configurable.
So
you
can
configure
your
your
host
to
your
your
receiver,
url
and
your
source
name,
because
it's
reflected
here
your
source
name,
so
you
can
configure
it
from
yaml
file,
and
here
is
the
symbol.
So
the
sender
in
this
case
it
is
just
basically
an
and
cmd
application.
A
A
So
I
I
can
show
you
like
how
we
exactly
execute
a
command
using
the
cli,
it's
a
very
similar
to
for
what
we
have
in
google.
So
we
have
the
the
binary.
It's
not
binary,
it's!
Okay!
It's
just
this!
It's
it's
a
buying
package
and
we
just
receive
the
metadata.
A
A
A
That's
basically
what
we
have
built
it,
what
we
have
built-
and
we
have
we
have
couple
of
things
about
like,
for
example,
we
have
educated
application,
we
have
probably
tested
fully
covered
tested
for
the
application,
and
everything
is
it's
it's
executed
by
me,
so
you
can
make
tests
and
it's
tested
all
the
application
and
also,
if
you
don't
want
to
install,
buy
some
stuff,
you
can,
you
can
have
a
docker,
you
can
have
it
through
docker.
B
A
A
What
we
have
done
with
with
the
bison
apk,
we
still
have
kind
of
a
future
vision.
What
we
can
do
we
would
like
to
have
kind
of
receiver,
so
that
was
that's,
why
we
prepared
the
core
to
be
able
to
understand
the
object.
So
when
you
receive
the
object,
you
will
understand,
this
is
kind
of
art
factor
of
it.
C
Thanks
tarek
just
wanted
to
mention
so
the
goal
for
this
first
version
has
just
been
to
like
try
to
be
on
par
with
the
current
go
sdk
now
the
go.
Sdk
is
changing
as
well,
which
I
think
is
good
and
we
have
a
static
mentioned
plans
for
for
the
python
sdk
as
well.
So
something
that
that
should
be
discussed
is
how
similar
do
we
want
the
different
sdks
to
be.
C
D
Yeah,
so
I
I
think
idiomatic
is
really
important
for
language.
You
know,
like
being
you
know,
if
you're
a
go
engineer,
for
example
right
and
you're
using
an
sdk,
you
expect
it
to
be
idiomatic,
go
right,
and
if
it's,
if
it's
not
idiomatic
go,
then
it
makes
it
a
little
painful
for
someone
to
use
it's
not
like
it's
not
a.
You
know
like
a
killer,
but
it
is.
It
makes
it
more
painful
because
they
have
these
sort
of
set
expectations,
so
I
definitely
think
having
it
be.
D
You
know
something
that
that
the
language
is
used
to
whatever
that
com.
Those
conventions
are,
I
think,
is
really
really
important
for
for
the
end
user.
So
that's
kind
of
like
my
two
cents
on
that.
C
Yeah,
I
think
that
makes
sense,
and
I
think,
even
if
that
means
that
the
sdks
don't
end
up
being
as
similar
as
they
could
have
been
with
some
good
example
code,
people
will
hopefully
find
it
quite
easy
to
to
move
from
one
sdk
to
the
other,
given
that
they
have
understood
the
base
concepts
from
using
one
of
the
sdks.
That's
that's
what
yeah.
D
Exactly
I
think,
that's
perfect
and
then
one
thing
that
I
kind
of
want
to
call
out
because
I
like
in
the
last
I
haven't
been
to
this
to
the
sig
meetings
in
the
last
couple
of
weeks.
Sorry,
I've
been,
you
know,
I've
been
out
on
vacation,
but
I
did
mention
that
I
have
a
lot
of
experience
with
sdks
and
one
thing
that
I
noticed
is
that
you
guys
are
using.
You
know
you
guys
have
a
lot
of
these
shared
models.
Have
you
guys
considered
using
something
like
swagger?
D
You
know
open
api
or
smithy
or
any
of
these
modeling
languages
to
kind
of
generate
these
shared
objects.
So
you
know
when,
when
you
make
one
change
in
one
sdk,
all
these
objects
get
updated
throughout
all
the
sdks
right.
So
it's
kind
of
hap
enforces
that
that
consistency.
C
Yeah,
that's
definitely
something
that
we
have
discussed.
I
think
we
even
have
like
an
issue
or
something
on
the
roadmap
related
to
that
it's
early
days,
right
now,
but
definitely.
B
C
D
Okay,
perfect,
perfect
yeah,
because
I,
I
think
it'd
be
a
good
idea
to
wrap
start
it
earlier
rather
than
later.
Just
because,
like
my
worry,
is
you
know
if
things
start
to
diverge
in
any
way,
you
know
like
fixing
those
or
like
generating
that
code
is
going
to
be
a
breaking
change.
So
I
think
I
think
we're
especially
now
that
we,
I
think
we
have
three
sdks.
D
We
have
the
go
python
and
java
right,
so
I
think
we're
at
a
good
place
to
actually
start
start
doing
that,
and
then,
on
top
of
that
I
was
curious.
Like
do
you
guys
have
a
link
to
the
go
sdk,
because
I'm
trying
to
find
it-
and
I
just
see
this
main
branch
but
there's
no
code
in
it.
C
So
it
hasn't
been
moved
yet
there
is
an
issue
for
that
as
well,
but
and
that
work
hasn't
been
done.
D
So
how
easy
is
it
for
me
to
like
use
or
modify
any
of
this
like
what
I
mean
by
that,
like
let's
say,
I'm,
I'm
a
user
right
and
I'm
I'm
I'm
using
this
sdk
and
I
wanna.
Can
I
inject
like
a
handler?
Is
there
an
easy
way
to
kind
of
customize
the
the
request
going
to?
D
I
guess
to
this
event
store
this
receiver,
because
I
can
definitely
see
like
maybe
at
wanting
to
add,
like
some
sort
of
custom,
maybe
authenticator
payload
or
something
of
that
nature
may
be
important
or
might
be
interesting
to
the
end
user.
You
know
just
like
being
able
to
customize
how
the
the
command
gets
executed.
If
you
will
giving
that
flexibility
to
the
end
user
is.
Has
that
been
thought
about
at
all.
C
D
Okay,
cool
cool
yeah.
I
found
I
found
the
go
sdk,
so
I
might
be
able
to.
I
I'll
have
to
talk
to
my
manager
and
see
because,
like
I
said,
like
you
know,
being
I'm
at
I'm
at
apple
and
we're
very,
very
protective
on
like
what
I
can
contribute
code
wise.
But
if,
if
I
can't
contribute
code,
wise
I'll
definitely
create
issues
or
comment
on
pull
requests
and
see
what
I
can
do
there.
C
That
sounds
good,
really
good,
yes,
and
did
anyone
have
anything
else
for
tarek.
B
No
just
want
to
say
thanks
for
doing
this.
I
mean
it
looks
like
a
great
start
and
I,
like
all
the
packaging
options
that
you're
giving
it
as
well.
So
that's
really
handy.
I
think
it
would
be
good
to
to
get
this
into
the
cd
event
org,
so
yeah
yeah.
C
A
Have
I
have
a
question
for
my
understanding
why
we
would
like
to
keep
it
in
a
specific
object's
name
like,
for
example,
we
would
like
to
have
something
called
artifact
or
something
called
building
like
why
we
don't
have
it
as
a
dynamic
and
each
object
represented
with
cover
of
metadata.
Everything
is
in
json
file
and
this
kind
of
dynamic
to
send
or
to
create
whatever
additional
event
you
need
like.
Why
are
you
limited
to
this
kind
of
events.
C
C
Otherwise
I
mean,
if
you
want
to
be
able
to
send
anything
and
receive
anything,
then
the
answer
would
be
cloud
events
that
that
is
the
protocol
that
you
use
to
be
able
to
send
anything
and
receive
anything.
So
cd
events
is
a
next
or
it's
a
I'm,
not
sure
what
it
called
an
extension.
But
it's
a
specification
on
top
of
cloud
events
or.
C
It
that
says
here
are
a
bunch
of
messages
explicitly
that
you
can
send
and
we
promise
that
these
events
mean
something
and
and
that
the
receivers
will
be
able
to
understand
them,
and
then
I
mean
if,
if
users
want
to
send
cloud
events
next
to
cd
events,
that's
there's
nothing
preventing
that
they
can
send
whatever
they
want
using
cloud
events,
but
that's
not
the
purpose
of
the
sdk,
the
cloud
events
sdk
can
be
used
for
that.
Our
sdk
should
specifically
send
and
receive
cd
events.
That's
that's
my
view
on
it.
B
Yeah
and
ultimately,
we
will
need
to
create
a
set
of
conformance
tests
so
that
we
can
verify
that
the
sdks
are
producing
the
events
that
want
and
we
need
to
for
those
tests
and
in
the
different
languages.
So
we
can
make
sure
that
you're
doing
the
right
thing
and
you
know
the
sdks
and
that's
I
mean
even
if
we
generate
them
or
some
part
of
them
for
some
automation.
I
think
still.
We
will
need
to
have
like
consistent
testing
across
csc
case.
C
Yes,
so
I
I
added
some
stuff,
then,
as
the
next
bullet
sdk
readiness
checklist.
Basically
thinking
about
what
does
it
mean
to
have
a
first
version
of
the
sdk
as
static
has
shown?
Now
we
we
have
the
python
sdk
to
a
level
where
we
can
send
events
primarily
through
the
cli,
but
it
would
be
possible
for
other,
like
applications
or
scripts,
to
use
the
core
module
and
and
send
events
using
that
receiving
events
is
not
something
that
we
have
right
now,
but
tarek
has
started
to
think
about
how
to
implement
it.
C
C
I
will
will
steal
the
the
concept
that
ben
brought
up
idiomatic
if
it's
idiomatic,
in
whatever
language
that
you're
talking
about
to
have
classes
for
these
event
types
for
python.
I
guess
it's
50
50,
depending
on
what
school
of
python
you
happen
to
subscribe
to.
C
I
am
an
object-oriented
person
by
heart,
so
I
love
the
typing
thing
and
class
support
in
python
and
would
like
to
have
proper,
documented
type
hinted
classes
for
every
single
event
type,
so
that
when
I
receive
an
event
or
send
an
event,
I
send
an
object
of
a
very
specific
class,
preferably
immutable
as
well.
So
I
know
what
I'm
doing,
but
it
doesn't
have
to
work
like
that.
We
could
do
more
of
a
dynamic
approach,
relying
more
on
like
dictionaries
and
those
kind
of
things
to
to
not
have
to
have
as
much
code.
C
D
So
I
I
am
very
opinionated
on
this
portion
of
things,
mostly
because
of
documentation
when,
when
you
have
defined
classes,
users
know
what
to
expect
and
they
can
easily
go
to
the
documentation
and
find
it.
And
if
it
is,
you
know
a
strongly
typed
and
they
can
do
that
just
all
through
code
right.
They
can
just
go
to
the
class
and
see
you
know
what
the
the
necessary
you
know.
D
Fields
or
types
are
right,
but
if
it's
just
a
dictionary,
if
you
go,
you
can't
go
to
the
fields
in
the
dictionary
right,
like
the
dictionary,
is
just
a
dictionary.
So
it's
good.
I
think
it's
going
to
be
harder
for
users
to
understand
like
what
this
object's
going
to
look
like
look
like
right.
So
I'm
more
I'm
I
agree
with
you
eric.
I
am
100
in
the
you
know,
object-oriented,
you
know
I
think
all
classes
should
should
be.
D
I
guess
strongly
typed
as
as
much
as
possible,
because
in
the
end
it
does
make
it
easier
for
for
users.
C
D
E
C
Yeah
good,
that
sounds
really
good,
so
my
final
question
on
that
topic
was:
is
there
anything
else
that
we
should
like
have
in
the
readiness
checklist
when,
when
we
have
support
for
sending
receiving
events,
and
we
have
classes
for
all
the
different
events
that
we
have?
Maybe
that's
good
enough
for
a
first
version
of
an
sdk.
It
should
be
enough
for
people
to
use.
D
C
D
Okay,
well,
if
that
was
okay,
I'm
going
to
go
off
of
what
andrea
had
said
earlier,
because
I
I
think
this
is
really
important
because
having
cross
com
compatibility
tests
between
the
sdks,
the
reason
why
I
say
that
is
because
if
you
have
one
sdk
that
isn't
generating
the
right
thing
you
know
is
but
ascending
events,
and
then
you
have
another
sdk,
that's
trying
to
like
read
or
you
know,
is
also
sending
events
but
they're
different.
D
You
know
that
like,
if
you
try
to
fix
that
later
on,
even
if
it's
even
a
small,
a
small
difference
right,
that's
going
to
be
a
breaking
change
for
people
that
are
using
it
or
even
in
the
event
store
right.
You
can
have
a
lot
of
issues,
I'm
trying
to
fix
that.
So
that's.
E
But
on
top
of
the
test
cases,
I
think
we
should
also
require
some
kind
of
documentation
stating
in
the
appropriate
documentation
structure
for
the
language,
whether
it's
oxygen
or
whatever
for
different
languages.
C
D
B
Okay,
one
question
was
about
the
the
cli,
so
at
the
moment
we
we
have
cli,
you
know
python,
we
have
the
cli
and
go
I.
I
wonder
whether
we
should
have
one
cli
and
have
all
the
other
sdks
being
just
as
the
case
or
if
you
want
to
support
like
having
a
cli
to
send
events
in
multiple
languages
as
well.
C
Basically,
that
only
one
of
the
sdks
would
need
to
have
a
corresponding
cli
application
connected
to
it,
and
I
think
that
made
that
make
sense.
There
isn't
really
that
much
of
a
use
case
to
have
multiple
clies,
because
then
there
are
multiple
things
that
we
need
to
to
keep
up
to
date.
The
reason
we
built
it
for
the
python
sdk
was
just
to
to
like,
as
a
first
step,
make
it
do
exactly
what
the
go
sdk
does
just
to
have
a
starting
point.
C
D
Yeah
go
is
cross-platform
strongly
type
good,
cli
language,
but
also
python
is
also
a
great
cli
language.
So
I'm
okay
with
either
probably
the
better
option
is
probably
python
just
because
it's
easier
to
distribute
because
you
don't
have
to
make
all
these
other
binaries
for
all
the
other.
You
know
machine
platforms,
so
I
would
probably
lean
more
towards
python
just
because
it
makes
releases
easier.
You
just
release
the
python,
you
know
cli
and
you're
done.
You
don't
have
to
worry.
D
C
C
C
I'm
not
sure
tarek.
Do
you
know
if
the
this
cloud
events
python
sdk
does
that
require
any
particular
python
version
like?
What's
the
minimum
python
version
you
can
use
for
the
cloud
event,
sdk.
A
No,
I
I
don't
know
actually,
but
in
in
my
case
I
used
a
feature
already
exists
in
3.9,
so
yeah.
I
say
I
think
we
can
have
much
much
much
easier
solution
is
to
in
in
the
situation
or
in
the
case
or
the
cli
to
the
window
unlocker.
So
you
can
have
like
docker
image.
You
just
want
cover
of
parameter
and
it's
execute
whatever
you
need.
So.
C
But
yeah
then
for
the
python
sdk.
But
that's
something
for
me
antarctic
to
think
about
a
bit.
I
guess
is:
maybe
we
should
aim
for
a
much
lower
minimum
python
version,
something
like
3.4
or
something
that
basically
everyone
has
nowadays.
But
it
depends
on
what
the
cloud
events
sdk
uses
for
minimum
platform
version
yeah,
but.
B
Okay,
cool,
and
so
we
have
good
discussion.
I
think
we
we
can
create
an
issue
to
track
the
cli
specific.
I
can
do
that
thanks
out
there.
B
Yeah,
I
think
both
python
and
go.
They
have
their
plus
and
pros
and
cons,
but
yeah.
So
that's
discuss
it
on
the
issue.
So
anything
else
on
the
python
side
of
things.
B
All
right,
moving
on,
I,
I
started
working
a
new
version
of
the
go
sdk
and
the
reason
for
it
for
a
new
version
to
exist.
To
begin
with
is
that
the
the
spec
has
changed
or
is
changing
compared
to
where
the
original
go.
Sdk
was
written
and
yeah,
so
I
wanted
to
to
make
an
sdk
that
was
focused
on
the
sdk
side
of
things
and
we
can
build
the
scli
as
well,
but
yeah
I
wanted
to
make
sure
we
have.
The
sdk
is
the
focus
yeah.
B
So
I
I
had
some
I
started
working
on
it.
I
had
some
ideas.
I
can
go
through
the
ideas,
if
that's
okay,
but
just
to
to
show
how
this
the
sdk
would
look
like
from
a
user
point
of
view.
B
Object
that
can
be
created
through
source
and
subject
id
things
like
version
the
event
id
timestamp
subject.
Source
are
set
automatically
that
can
be
overwritten,
and
then
I
would
have
like
a
subject
content
interface
with
multiple
implementations,
and
what
does
that.
B
B
A
A
As
far
as
I
saw
that
the
old
goal
is,
the
key
I
was
thinking
like
there
is
a
there
is,
might
be
a
very
good
space
for
for
using
genetics.
Since
it's
a
it's
a
new
end
goal.
I
didn't
use
it
actually
so
much,
but
I
think
there
is
an.
I
might
be
a
good
space
to
start
using
genetics,
since
the
application
heavily
depend
on
multiple
time.
Inheritable,
perhaps
the
same
specification
for
this
type.
So
I
was
thinking
you
might,
you
might
start
thinking
about
using
generic
single.
D
Yeah
I
was
going
to
mention
something
similar
just
because
I
saw
that
empty
interface
in
the
in
that
subject,
content,
but
I
don't
know
if
you
can,
if
you
can
solve
that,
because
I'm
I'm
imagining
the
key
and
value
or
the
value
can
be
all
but
arbitrary,
like
any
type,
is
my
guess,
so
it
might
be
a
little
hard
to
use
generics
there,
but,
like
I
said
I
would
have
to
see
the
use
case
and
then
one
thing
that
might
be
useful.
D
I
can't
actually
ping
you
offline,
andrea
and
then
kind
of
go
over
like
what
you
what
you've
written
because,
like
I
said,
I
have
a
lot
of
experience
with
go,
so
I
might
be
able
to
provide
some
really
good
feedback
in
time.
In
terms
of
just
you
know,
writing
idiomatic
go
as
well.
As
you
know
some.
You
know.
D
Good
ideas
like
like,
like
I
was
talking
about
earlier,
adding
like
handlers
or
hooks
to
allow
users
to
to
like
listen
for
a
certain
event
or,
like
you
know,
when
they
create
create
an
event.
You
know
that
that
can
be
post
or
a
hook
to
be
executed
after
the
fact.
So
so
yeah.
B
Yeah
sure
absolutely
yeah
I
mean
we
can
chat
further
offline.
If
you
want,
I
mean
this
is
a
very
starting
point,
but
yeah,
I
guess
the
main
thing
is
the
main
dilemma
in
the
beginning
is:
do
we
want
to
have
like
a
core,
an
overall
different
object
for
every
event
or
trying
to
do
something
like
this,
where
we
have
like
one
city
event,
interface
that
can
support
multiple
different
bodies
and
so.
D
I
think
I
think
you
want
an
object
or
a
definition
per
per
event
type
right,
because,
if
you're
receiving
an
event
and
go
like
I
imagine,
you
would
want
that
to
be
an
actual
strut
right,
as
opposed
to
like
a
mac
string.
Interface
like
working
with
empty
interfaces
and
go
is
like
the
worst
thing.
So
so
that's
why
I
I
I
really
think
you
know
per
event
makes
the
most
sense
and
you
can
see
what
you
did
right
there
like
that
pipeline.
One
queue.
Subject:
content
you
can
do
that.
D
You
know
it's
it.
You
know
you
can
create
that
that
strut
right
there.
You
know,
as
opposed
to
a
map.
You
know
you
can
do
the
same
thing,
but
it's
just
now
a
map
right.
So
but
now
you
have
to
know
the
keys
of
the
of
the
map
and-
and
I
think
that
makes
it
more
of
a
pain
as
opposed
to
just
you
know,
going
to
the
documentation
or
looking
at
the
code
or
using
the
ide
to
fill
in
those
those
necessary
fields
right.
B
Right
yeah,
so
the
question
is,
I
mean:
do
we
want
to
because
of
the
context
they
share
for
all
the
events?
So
it's
the
same,
so
I
can
add
a
type
for
the
context
side
and
then
just
make
a
type
that
uses
make
multiple
types
that
reuse
the
context
and
then
add
the
new
one
or
like.
This
is
the
way
I
I
I
was
thinking
of
creating
it
but
yeah
I
can.
I
can
switch
back
to
to
having
like
top
level
specific
type
if
it
makes
sense.
B
Maybe
what
I
can
do
also.
I
can
prototype
both
approaches
so
that
you
can
compare
in
the
code
how
they
would
look
like
and
yeah.
We
can
discuss.
B
B
Okay
yeah
for
the
cli,
I
mean
we
discussed
already
before
so
maybe
there
will
be
a
cli
go.
Maybe
yes,
we
can
refer
to
the
other.
B
Okay,
anything
else
on
the
go
sdk.
B
Okay,
cool
yeah,
so
right
now,
I'm
working
in
a
in
a
branch
on
my.
A
B
D
Yeah,
that
would
be
awesome
either
either
one's
fine
yeah
I'll
ping.
You,
after
after
this
meeting
cool.
B
Yeah,
so
the
last
thing
I
had
on
the
on
the
agenda
for
today
is
discussion
about
binary
structure
mode,
so
I
went
back
and
talked
to
the
cloud
event
folks
about
this,
and
basically
so
just
to
to
summarize
so
I
had
an
idea
that,
based
on
also
ban
inputs,
that
we
could
try
and
have
a
binary
mode
for
cd
events
and
the
reasoning
for
that
would
be
to
basically
allow
cd
events
to
transport
and
untouched
payload
from
vendor
and
and
the
way
to
achieve
that
would
be
to
get
cd
event
specific
content
into
into
headers,
http,
headers,
basically
or
some
kind
of
feather,
depending
on
the
protocol
that
is
used
but
yeah.
B
So
the
problem
with
that,
after
talking
with
the
cloud
event
folks,
it
seems
that
existing
implementation
of
cloud
events
routers,
they
would
drop
these
extra
headers
because
they
not
known
to
them.
So
they
would
only
transport
things
which
are
cloud
event
specific
categories
or
something
in
http,
for
instance,
things
that
start
with
ce
dash
and
everything
else
will
be
be
ignored
and
it's
basically
this.
This
approach
would
kind
of
break
the
payload,
sorry
the
encapsulation,
so
it
doesn't
seem
to
be
a
valid
option
really.
D
One
one
thing
that
is
a
little
confusing
to
me
is
why
don't
they
just
have
a
header
which
is
like
x,
dash
cd
events
dash
like
metadata
or
something
that
you
can
put
whatever
you
want
in
there
or
just
have
multiple
of
those
headers
and
they
don't
drop
them.
That
seems
like
an
easy
and
and
most
standards
like
support,
some
or
like
most
http
standards,
support
something
like
that.
Where
a
header
needs
to
be
have
you
know
arbitrary
headers
can
be
added,
you
know
they.
B
Yeah,
that
is
possible.
I
mean
they
have
a
concept
of
extensions,
so
you
can
define
cloud
event
extensions,
so
you
basically
define
ce
dash,
something
fields
and
those
something
are
your
your
fills,
but
it
becomes,
I
think,
a
bit
cumbersome
to
include
everything
in
this
such
extensions.
I
mean
we
could.
B
Have
multiple
a
very
large
number
of
extensions,
because
we
would
need
multiple
ones
for
each
event
type
or
we
could
go
down
the
the
route
of
saying.
Okay,
we
take
everything
that
we
would
send
us
from
the
cd
event
body
and
may
64
encode
it
and
put
it
in
a
single
header,
for
instance.
That
could
be
a
way
of
doing
it,
but
it's
not
very.
B
D
Okay,
so
if
we're
not
going
to
go
that
route,
so
are
you
suggesting
that
we
add
a
new
field
to
the
vendor
data,
because
the
issue
there
right
is,
if
you
have
some
service
down
the
line
that
doesn't
use
the
event
that
vendor
data,
that
new
field
is
also
going
to
be
dropped
right?
It's
the
same
issue.
B
So
the
the
problem
is
something
also
that
matthias
pointed
out:
that's
an
additional
problem,
even
if
we,
even
if
we
manage
to
con
to
have
the
same
exact
content.
Let's
say
we
we
take
action.
For
instance,
it
sends
cloud
events
already
and
we
want
to
keep
the
same
content
as
tecton
sense
today,
but
we
also
want
to
send
a
cd
event.
B
Even
if
we
manage
to
keep
the
same
exact
payload
that
the
event
type
is
different,
so
a
receiver
that
expects
to
have
a
certain
event
type
would
not
see
they
then
type
that
he
expects
it
will
see
a
cd
event
event
type.
So
I
think
the
the
solution
for
ending
multiple
type
of
receivers
would
be
then
to
send
multiple
type
of
events.
B
D
Okay,
yeah
yeah.
I
I
think
that's
fair,
like
I
said
like
as
long
as
we're,
not
touching
the
payload.
I
think
that's
fine!
So
are
you
thinking
that
this
new
field
exists
in
the
sdk
right,
we're
not
adding
this
to
to
each
model
that
the
customer
has
in
their
service
right
or
are
we.
D
D
B
Basically
yeah
when,
when
you
use
the
sdk,
you
would
say
data
and
then
in
in
this
data
field
in
the
sdk,
you
would
set
your
your
model
and
that
everything
is
combined
for
you
by
the
sdk.
If
it
makes
sense.
D
B
Let
me
open
the
respect.
I
mean
yeah.
This
is
up
for
discussion,
of
course,
and
we
have
not
defined
it
yet,
but
let's
see
yeah
decent.
B
So
right
now,
this
is
like
what
the
json
looks
for
a
city
event.
What
it
looks
like.
We
have
a
context.
We
have
a
subject,
so
we
could
have
an
extra
one,
which
is
data
and
we
have
the
vendor
data
in
there
so
that
that
was
kind
of
the
option
I
was
thinking
of
and
then
from
the
sdk
point
of
view.
When
you
create
your
event,
you
can
pass
in
your
data.
D
B
B
So
the
new
field
would
be
at
the
same
level
I
mean
could
be
at
the
same
level
as
contact
context
and
subject.
I
was
thinking.
D
Yeah
yeah,
but
no,
no,
what
I
mean
is
the
where,
where
the
where
the
new
field
is
modeled
is
where
I
is,
what
I'm
asking
is
the
new
field
when,
in
the
definition
right,
let's
say
I
have
this
class
in
my
service?
Let's
call
it,
you
know
thing
descend
class,
you
know.
So
this
thing
descend
class
has,
let's
say:
name
is
a
string
and
then,
let's
say
an
int
value
right.
So
those
are
the
two
fields
in
it.
D
Because
what
I'm
wondering
is
is,
is
the
customer
going
to
have
to
change
all
their
models?
That's
what
this
comes
down
to
are
all
the
customers
now
need
to
go
and
add
this
field
to
satisfy
this
new,
this
spec,
essentially,
which
is
fine
right,
but
I
just
want
to
make
sure
I'm
understanding
like
where
this
thing
is
being
added.
B
D
Yeah
yeah,
no,
I
think
that's
fine,
I
think
in
the
github
issue
I
I
proposed,
like
you,
know,
adding
an
extra
field
right,
which
I
think
it
makes
it
really
really
straightforward
so,
and
I
actually
prefer
that,
as
opposed
to
the
headers
one,
I
think
it's
more
flexible,
so
so
I'm
actually
I'm
actually
plus
one
for
this.
I
really
think
it's
a
good
idea.
B
All
right,
so
I
will
make
a
pr
to
remove
what
we
have
in
the
spec
today
in
terms
of
binary
content
mode.
I
mean
it's
not
much,
but
we
have
like
this
headers.
That
needs
to
be
filled
and
some
comments
here
in
the
content
mode.
So
I
will
remove
the
dimensions
from
the
binary
and
I
will
make
a
proposal
then
for
for
this
new
data
field
yeah.
So
we
can
review
those
and
hopefully
merge
them
in.
B
All
right,
so
we
are
almost
at
time.
D
I
still
have
some
questions,
but
mostly
like
how
how
would
this
new
field
be
popular
like
what
would
exist
in
this
right
like
how?
How
is
it
getting
this
data?
I
guess
is
my
question
right:
is
it
point,
is
it
like
have
does
this?
Does
the
vendor
data
have
like
metadata
or
like
annotations
like
how?
How
is
it
populating
this
new
field.
B
Yeah,
I
guess
we
will
need
to
to
maybe
take
a
specific
example
and
try
to
to
see
details.
How
this
would
look
like
I
mean
the
way
I
see
it.
I
mean
there
is
one
constraint
with
this
approach.
I
said
that
this
data
would
be
either
json
or
if
it's
not
json,
it
would
have
to
be
kind
of
base64
encoded
so
that
you
can
put
it
in
json
there,
because
it's
it's
part
of
a
json
body.
B
B
D
Yeah
I
have,
I
have
a
few
ideas,
but
the
only
issue
is,
I
don't
know
if
you
can
do
it
in
python.
You
probably
can
because
python
can
do
anything,
but
but
my
knowledge
of
python
is
very
limited,
so
I
can,
I
can
maybe
propose
like
once
once
you
create
this
pr
I
can.
I
can
give
maybe
a
an
idea
and
then
someone
with
like
python
experience
could
say:
hey
this
isn't
possible
or
hey.
This
is
possible
in
python.
D
B
Yeah,
I'm
sure
we
should
be
able
to
to
do
things
in
python
and
go
I
mean
they're,
both
pretty
flexible,
so
yeah
yeah,
all
right,
yeah.
We
are
time
for
today
but
great
to
see
everyone.
Great
discussion
and
yeah
see
you
in
the
next
meeting
and
watch
out
earlier.
As
luck.