►
From YouTube: CDEvents / SIG Events Vocabulary Meeting - June 14, 2022
Description
For more Continuous Delivery Foundation content, check out our blog: https://cd.foundation/blog/
A
B
B
C
C
So
a
couple
of
things
I
added
in
the
agenda
for
today
just
briefly
some
updates
links
to
the
white
paper
project
announcements
with
a
few
articles
in
the
news.
If
you
want
to
go
and
read
them,
so
that's
good
coverage
and
then
the
things
that
I
had
planned
that
I
put
in
the
agenda.
But
let
me
know
if
there
are
other
things
that
you
would
like
to
discuss.
C
C
And
then
I
put
a
few
a
couple
of
discussions
on
the
spec
that
we
could
have.
One
is
the
payload
structure
triggered
by
some
an
issue
that's
created
by
ben.
So
thanks
for
that-
and
there
was
one
issue
about
dependency
updates
that
you
created
emil
and
yeah.
I
don't
think
I'm
not
sure
I
don't
think
it
has
been
introduced
to
the
group.
Yet
so
maybe
it's
an
opportunity.
C
D
A
A
C
B
C
C
C
C
C
C
So
next
one
is
capture
our
key
use
cases
and
design
decision
in
the
cd
events
private
document.
So
I
think
the
use
cases
are
captured
now
and
thanks
matthias
for
setting
up
this
this
page.
So
a
couple
of
things
that
are
left
to
do
here,
I
think
adding
a
link
to
the
white
paper
and
maybe
host
it
on
our
sdevents.dev.
C
D
C
So
we
have
on
one
side
the
spec
on
the
other
ones,
on
the
other
side,
like
kind
of
track
of
the
design
decision.
We
are
doing
the
spec
like
this
because,
like
we
decide
to
keep
the
payload
or
not
keep
the
payloads
in
the
in
the
events,
because
we
have
certain
backward
compatibility
requirements
or
like
this
kind
of
content,
but
I
would
say
yeah,
so
we
can.
We
can
document
that
practice
and
then
close
this
issue,
and
then
this
will
be
like
an
ongoing
work.
So.
C
C
Yeah,
so
I
think
a
lot
of
ids
are
specific
to
sources
of
events,
and
this
item
was
to
about
like
defining
what
a
server
should
look
like
in
terms
of
structure
and
having
some
recommendation
in
the
specification
about
how
to
express
a
source.
If
I
want
to
say
these
events
come
from
this
platform
or
this
cluster,
is
there
like
a
recommended
format
that
we
can
use
to
do
that.
C
System
already
produce
and
consume
cloud
events
when
a
producer
starts
producing
cd
events.
In
addition
to
existing
cloud
events,
not
all
consumers
may
be
ready
to
consume
city
events,
so
how
we
solve
these
a
couple
of
ideas
either
sends
both
events
or
send
cd
events
that
are
backward
compatible,
and
this
links
back
to
the
points
that
you
brought
up
then
so
can
we
send
cd
events
that
are
still
compatible
with
existing
cloud
events
so
that
a
consumer
can
still
consume
the
events?
C
C
A
C
Having
a
component
that
is
able
to
translate
from
github
to
city
events,
this
is
something
that
is
probably
going
to
be
used
in
many
pocs
and
also
so
mauricio
mentioned
that
you're,
probably
quite
close
to
have
that
available.
So
I
tentatively
assigned
him
to
this,
and
I
think
it's
something
that
would
be
good
to
maintain,
at
least
in
the
beginning.
C
A
B
A
C
A
C
C
A
C
D
A
B
Yeah
yeah,
so
I
definitely
thinking
have
like
an
initial
like
statement
on
0.1
is
a
good
because
that
tells
you
know,
players
that
are
that
are
maybe
committing
to
the
an
early
version
that
you
guys
are
thinking
about
it
right.
So
I
think
I
think
it's
a
really
good
idea
and
then
yeah
and
then
one
caveat
is
like
we
don't
want
to
wait
for
a
breaking
change
to
happen
and
then
start
thinking
about
it
right.
So
we
want
to
make
sure
that
we
are.
We
are
thinking
about.
B
C
C
I
created
an
issue
today
on
the
cd
events:
oh
the
java
sdk,
but
yeah,
I'm
not
sure.
If
you
yeah,
I
started,
I
started
reviewing
all
the
issues
on
the
sleek
events
and
trying
to
highlight
which
are
the
the
ones
that
are
specific
to
cd
event.
Sorry,
on
the
seek
events.
This
is
they
identify
which
are
specific
to
cd
events.
Yeah,
that's
but.
B
I'm
curiosity,
this
is
kind
of
like
towards
the
bottom,
it's
more
technical
than
anything
else.
How
are
you
got?
Do
you
guys
use
a
modeling
language
to
generate
the
sdks,
or
do
you
guys
write
this
all
by
hand,
because
I
can
definitely
see
it
being
a
lot
easier
if
you
guys
use
something
like
swagger
or
some
sort
of
modeling
language
to
actually
generally,
you
know,
have
every
sdk
general
be
generated,
and
then
you
know
maybe
adding
an
abstraction
layer
on
top
of
it.
I
feel
like
that,
would
save
you
guys
a
lot
of
time.
D
A
D
C
C
B
Yeah,
so
I
really,
I
would
have
to
see
like
how
the
java
sdk
is
structured,
but
if,
if
you're
mainly
dealing
with
like
api,
I
would
just
use
a
known
modeling
language
like
swagger,
there's
a
new
one
by
aws
called
smithy.
You
know
there's
lots
of
these
right,
so
I
don't.
I
don't
know
if
we
want
to
reinvent
the
wheel
there,
because
what's
great
about
these
tools
right
is,
they
are
already
supported
in
multiple
languages.
B
So,
like
you
can
be
you
can
you
know
you
don't
have
to
write
this
json
generator
right
for
for
go
for
java
right?
Instead,
you
can
just
use
swagger
and
then
immediately
go
to
java
import,
the
java
library
and
then
have
it
generate.
So
that's
one
caveat
that
I
think
is
beneficial
rather
than
just
using
json.
D
So
I
think
one
issue
that
we
probably
will
run
into
is
that
we
are
not
building
these
sdks
from
the
ground
up.
They
are
always
built
on
existing
cloud
events
sdk
and
I'm.
I
would
doubt
that
any
tool
sets
for
swagger
or
smithy
would
generate
bindings
to
the
cloud
event
sdk,
but
I
mean
that
might
be
a
pretty
small
part
that
we
can
solve
somehow
and
we
can
still
generate
the
bulk
of
it.
Using
some
schema
language
like
that.
B
Okay,
yeah
yeah,
definitely
yeah,
I
would
have
to
like
say
I
have
a
little
context
in
into
the
the
java
sdks.
But
if
you
want,
I
could
talk
with
you,
because
I
have
a
lot
of
experience
with
sdks.
I
I
you
know
have
four
to
five
years
doing
like
aws
sdks.
So
if
you
want
eric,
I
can
I
can
message
you
on
slack
and
then
we
can
kind
of
figure
out
like
what
a
good
idea
is
going
forward.
A
C
D
A
A
C
A
A
A
C
C
B
B
B
So
when
what
I
noticed
was
is
this
data
field
is,
is
nested
and
unfortunately,
if
you
want
this
standard
to
be
accepted
into
someone
like
aws,
that's
that's
a
that's
a
huge
breaking
change,
so
that's
a
breaking
change
for
customers
and
all
internal
people
that
use
aid
sdk
or
aws
services.
So
you
know
this
format.
This
payload
cannot
change
right.
So
it
needs
to
be
an
additive
change
for
this.
For
this
to
be
accepted
to
those
type
of
companies.
B
So
all
the
all
the
data
would
be
stored
in
the
headers
and,
what's
great
about
that,
the
biggest
pro
there
is
that
the
payload
is
completely
untouched.
So
for
someone
like
amazon,
that's
a
huge
win
like
they.
They
would
be
like
oh
you're,
not
touching
the
payload.
We
don't
have
to
change
anything.
You
know
we
just
have
to
take
your
sdk
and
and
we're
good.
You
know
that
that's
a
huge!
You
know,
like
you
know,
that
burden
of
labor
labor
is
really
really
small,
so
so
yeah.
B
So,
if
you're
complete
continuing
to
add
to
this,
maybe
headers
isn't
the
right
solution,
but
I
think
it's
definitely
something
worth
looking
at
and
so
the
second
approach
is
payload
and
then
metadata
as
an
additive
feature.
So
so
I
wrote
this,
you
know
a
quick.
You
know.
Xml
example
here
is
that
you
have
that
wow.
You
know
payload
there,
and
then
you
have
this
cloud
events
metadata,
which
contains
all
all
those
bucketed
items
that
are
that
are
important.
So
again,
what's
good
about
this
approach,
is
you
know
the
payload?
B
That
might
not
even
be
what
I
wrote
right.
It
might
be
something
that
aws
has
that's
been
funneled
back
up
into
cloud.
You
know
that
could
that's
solvable,
but
it
might
be
a
little
weird.
So
so
that's
one
thing,
but
in
my
opinion
it
might
be
the
one
of
the
better
of
the
solutions
and
then
this
the
loss
approach
is
a
hybrid
approach
where
things
like
id
spec
version
type,
I
think,
could
all
be
in
the
header.
B
And
then
you
have
this
metadata
feel
on
top
of
it
and
I
think
the
benefit
there.
You
kind
of
get
the
best
of
both
worlds,
so
you
get.
You
know
the
least
amount
of
changes
in
the
in
the
payload,
or
at
least
you
know
the
additive
section
of
the
payload.
You
know
you're
adding
just
what
is
what
is
you
know,
kind
of
necessary
there
as
well
as
things
that
you
know
that
won't
change
too
much,
which
is
like,
for
instance,
the
the
version
right.
That's
that's
never
going
to
change
right.
B
Just
having
that
in
a
header
I
think,
makes
a
lot
of
sense.
So
yeah,
that's
kind
of
the
three
thing
and
then,
like
I
started
comment
andre
about
versioning.
That's
why
I
kind
of
kept
it
short
here,
because
I
I
was
like.
Maybe
I
should
put
this
in
another
issue
and
and
yeah,
so
I
I
did.
I
wasn't
able
to
go
through
your
response
just
yet,
because
I
woke
up
and
then
I
was
oh,
he
responded,
but
but
yeah.
C
C
So
in
this
the
later
mode,
the
binary
mode
is
kind
of
the
default
in
the
sdks,
and
so
that's
what
we
have
been
using
so
far,
and
so
that's
that's,
that's
something,
and
the
other
thing
is
in
terms
of
where
we
put
the
the
actual
cd
events
part
side
of
things.
So
the
current
as
the
case
they
use
the
old
event
approach.
C
C
The
content
type
is
an
application
json
and
there
we
could
have
the
meta,
which
includes
the
specification
version
and
the
event
timestamp
then
more
details
about
the
subject.
So
in
this
case
it's
a
task
run.
So
we
have
the
subject.
Type
task
run
the
subject
id
and
some
more
content
like
we
want
to
know
which
task
this
is
specific
to
a
url
to
retrieve
this
task
run
python
that
is
associated
with
this
and
so
forth,
and
then
we
could
have
extensions.
C
B
Basically,
anyone
that
talks
to
anybody,
because
now
right,
if
you're
changing
what
that
data
looks
like
especially
the
payload,
if
I'm
trying
to
talk
to
a
service
that
does
not
adhere
to
your
standard,
like
you
know,
and
I
shouldn't
force
them
to
adhere
to
your
standard
right
like
now,
it's
gonna
be
a
you
know:
it's
not
gonna
work
at
all
right
so
like.
If
I
go
to
a
third
party
service
and
I'm
like
hey,
you
know,
I'm
I'm
gonna,
send
you
this.
You
know,
and
I
don't
wanna
have
this.
If
statement.
B
That's
like!
Oh
it's!
If
this
service,
you
know,
don't
use
your
sdk,
you
know
like
it
would
be
easier
just
to
use
the
sdk
and
then
just
send
my
data
right,
but
now
I
have
to
kind
of
like
pick
and
choose
which
services
and
know
what
form
or
what
standards
that
they.
You
know
that
they
adhere
to.
So,
if
you're
changing,
where
that
payload
is
located
one,
it's
a
breaking
change
and
then
requiring
that
knowledge
of
who
supports
what
is
going
to
be
very,
very
difficult.
I
think.
D
Then
you
should
be
using
some
other
like
more
of
a
transport
specification,
so
for
for
for
a
service
to
say
that
it's
cd
events
compliant
it
cannot
decide
on
its
own.
What
payload
to
send
it
has
to
follow
the
seed
event
specification.
Otherwise,
compliancy
doesn't
really
mean
mean
that
much
so,
and
I
definitely
see,
of
course,
that
this
would
be
a
heavy
burden
for
someone
who
is
not
sending
city
events
today
to
start
sending
city
events.
But
in
my
opinion,
that
is
an
expected
burden
that
that
we
will.
B
Have
that
burden
is
impossible
for
a
large
company
like
aws?
They
they
don't
know
like
what
service
b,
who
service
b
is
talking
to
right
and
then
service
c.
They
don't
know
who
and
then
all
the
way
to
z.
They
don't
know
who
they're
talking
to.
They
all
know
how
to
adhere
to
the
standard,
and
then
this
is
kind
of
a
domino
effect.
I
I
don't,
I
don't
think
that's
a
good
idea.
B
No,
no!
No,
I
understand
that,
but
the,
but
the
issue
is
you're
not
going
to
have
everyone
adhere
to
the
standard
at
the
same
time,
that's
just
impossible
right,
but
the
fact
that
you
guys
are
changing
where
the
payload
is
located
makes
the
adoption
of
this
almost
impossible.
Frankly.
So
the
issue
here
now
is:
if
service
a
wants
to,
you
know
start
using
cd
events.
They
have
to
wait
for
a
b
c
d,
e,
f
g,
all
the
way
to
z.
B
To
start
you
know
to
start
adhering
to
the
standard
in
a
massive
company
like
amazon,
google,
microsoft,
that's
never
going
to
happen,
people
you
know
they
all
kind
of
work
at
their
own
pace.
You
know
and
adhering
to
a
standard
like
that
is
going
to
be
a
huge,
a
huge
effort,
but
instead
you
could
say:
hey,
listen!
This
is
not
a
breaking
change.
B
You
know
you
just
use
the
sdk
and
just
adds
header
this
payloads
at
the
top
level,
and
what
that
means
is
that
all
these?
All
these
all
these
companies
now
don't
need
to?
You
know
upgrade
at
the
same
time
right
or
or
start
using
the
standard
at
the
same
time
and
no
one's
broken
right.
Things
continue
to
work
and
then
slowly
you
can
kind
of
roll
out
everyone
to
use
a
standard.
Oh
yeah,
sorry,
you
also
had
a
question
andrea.
C
C
But
that
would
break
captain
right
because
they
would
not
be
able
to
use
these
events
anymore,
so
having
a
mode
where
we
are
able
to
still
have
the
same
payload
as
captain
s,
but
we
also
have
the
city
events.
Information
in
would
allow
us
to
take
that
advantage
of
those
events
and
and
then
it
would
give
like
captain
a
transition
period.
A
time
over
time
to
you
know,
start
adding
the
cd
information
to
the
events,
information
natively
into
the
software
on
their
site
so
that
they
can
get
the
best
the
best
of
both
worlds.
C
So
because
of
these
I
was
thinking.
Maybe
we
could
have
two
modes
like
similar
to
what
we
have
in
the
in
the
cloud
events
sdk,
where
they
have
like
the
binary
modes
in
the
structure
mode
and
then,
if
you're,
having
like
a
binary
mode,
everything
all
the
cv.
Events
information
that
we
say
must
be
there.
We
put
it
into
http
adders,
but
we
know
that
there
are
some
limitations
in
just
using
the
http
header.
So
ideally,
we
would
like
to
have
things
in
the
payload
as
well.
C
B
So
the
two
modes,
so
I'm
very
familiar
with
this
in
in
a
lot
of
sdks,
so
usually
binary.
What
that
mode
is
typically
used
for,
is
for
streaming
right.
So
that
makes
sense
you
put
everything
in
header
payloads,
unchanged
right,
because
if
you
start
changing
what
the
payload
looks
like
that
streaming
service
is
gonna
break
right,
so
so
that
that
makes
total
sense.
B
You
know
you
know
useful
to
to
like
these
bigger
companies
right
or
useful
to
everyone,
not
just
bigger
companies
useful
for
you
know
for
everyone,
and
so
you
know
mode.
One
still
needs
to
have
this
payload
at
the
top
structure,
because
most
most
applications
are
using
the
rest
protocol
well
rest
or
some
form
of
it
right
and
some
platforms
do
use
the
streaming
binary
protocols.
You
know,
but
those
are
things
like
you
know
streaming.
D
C
B
C
B
B
C
Right,
so
if
I,
if
I
look
at
this
this
example,
it
would
basically
be
the
same
as
this
one.
The
only
thing
is
that
whatever
we
put
in
payload
here,
you
could
just
it
would
go
one
level
exactly
yes,
yes,
yeah,
so
the
only
problem
with
that
approach
then
is
yeah.
You
might
run
into
conflict,
naming
conflicts.
C
B
C
C
C
C
C
B
So
you
know,
I
definitely
you
know
want
to
have
more
discussions
around
this.
You
know,
but
it
definitely
needs
to
change.
If
you
want
the
level
of
adoption
and-
and
that's
my
thing
like
I-
I
want
to
see
this
get
into
places
like
aws
and
azure
and
gcp
I
want
to.
I
want
to
see
that
happen,
but
in
order
to
do
that,
you
need
to
make
sure
that
you
know
it's.
It's
easy
to
roll
out.
It's
easy
to.
B
D
B
Oh
yeah,
yeah
yeah,
definitely
yeah.
I
get
what
you're
saying
you
know
but
like
in
my
opinion,
like
you,
don't
want
to
be
just
limited
to
like
message,
busting
you
know
like,
and,
for
instance,
you
also
don't
want
to
like.
There
could
be
multiple
layers
before
you
reach
the
message
bus,
but
you
might
want
to
start
adhering
to
the
standard
like
way
early
on
right,
so
you
might
have
to
send
this
request
and
you
know
go
through
all
these
other
other
apis.
B
B
You
can't
do
that
that
when
I
see
things
like
this,
I
know
immediately
what
amazon
and
aws,
and
probably
what
azure
and
gcp
are
probably
going
to
say
when
when
they
see
the
standard
so-
and
this
is
why
I
brought
it
up
to
andrea
so
so,
if
if
you
want,
I
can,
you
know,
highlight
everything
that
we've
also
talked
about
in
this
github
issue.
Just
so
we
have
some.
You
know
visibility
and
then
hopefully
get
more
churn
and
have
the
community
react
to
it
more
and
see.
B
D
Because
another
way
to
go
about
it,
but
I'm
sure
I'm
missing
something
that
is
critically
flawed.
With
that
alternative
is
to
have
a
separate
channel
for
sending
seed
events,
then
it
wouldn't
be
a
breaking
change
to
anyone,
because
when
they
are
ready
to
listen
to
cd
events,
they
can
can
go.
Listen
on
the
seed
events
channel,
whereas
while
they
want
to
keep
the
background
compatibility,
they
listen
to
the
the
old
channel
instead
with
the
old
payloads.
But-
and
I
would
be
interested
to
hear
like
what
are
the
drawbacks
with
such
a
solution.
B
Yeah
yeah,
I
know
I,
I
think
you
know
that
you
know
a
perfectly
fine
solution,
but
the
only
issue
there
is
again
like
there
might
be
several
services
down
before
you
hit
this
message
bus.
So
you
have
to
expect
everyone
to
have
this
channel
right
and
then
again
with
this
channel.
How
many
apis
are
you
going
to
duplicate
just
to
now
support
cd
cd
events
right?
So
that
makes
your
code
base.
I
think
a
lot
more
complicated
and
larger,
and
I
think
you
know
to
simplify
that.
B
All
we
need
to
do
is
just
move
this
payload
up
one
level
or
up
as
in
like
you
know,
don't
nest
it
and
that
solves
all
those
issues
your
code
base
remains
the
same.
All
you
need
well
remains
the
same.
For
the
most
part,
all
you
need
to
do
is,
you
know,
adhere
to
or
use
sdk,
but
you
know
it's
not
breaking
anyone.
You
know
service
a
disservice.
You
know
lambda
or
service
prime
right,
they
they
aren't
gonna
they're,
not
gonna
ever
have
to
worry
about.
B
You
know,
did
I
you
know,
did
did
someone
down
the
line
not
adhere
to
the
standard
right?
They
they
know,
you
know
if
I
get
get
the
c
or
the
cd
event.
You
know.
I
know
that
you
know
it's
not
going
to
break
someone.
You
know
that
might
be
further
down
the
line
and-
and
you
know
how
do
I
know
you
know
what
api
channels
to
call
now.
You
know
like
it's
like
now.
I
have
to
go
talk
to
all
these
services
just
to
be
like
hey.
B
Do
you
have
a
cd
events
channel?
You
know,
so
I
I
think
I
think
that
definitely
well
like
I
said
it's
definitely
a
good
solution
but,
like
I
said
in
I'm
thinking,
I'm
thinking
at
scale
like
aws,
where
it's
that's
really
hard.
Our
those
teams
are
very,
very
siloed.
So
now
you
have
to
go
kind
of
like
running
around
talking
to
all
these
people
just
to
ensure
that
they
support
all
these
channels,
which,
which
is
gonna
be,
which
is
quite
difficult
to
do.
D
Yeah-
and
I
guess
that
is
a
use
case-
that
we
definitely
haven't
discussed
this
use
case
where
there
are
several
layers
of
services
that
need
to
contribute
to
a
single
cd
events
being
sent
at
some
point
or
not
even
sent
but
being
understood
by
someone.
I
think
all
of
the
use
cases
that
we
have
talked
about
so
far,
it's
pretty
much
that
whatever
service
or
application
is,
is
performing
something
related
to
cd
events.
That
immediately
has
the
opportunity
to
send
the
event
directly
and
doesn't
need
to
go
through
anything
else.
A
B
B
Okay,
perfect,
so
what
I
could
do
is
I
could
copy
this
github
issue
and
move
it
over
to
them
and
say:
hey,
listen!
These
are
you
know.
I've
been
talking
with
cd
events.
These
are
some
of
the
issues
that
we've
been
talking
about
and
and
see
how
they
address
it.
If
that,
if
that's,
if
you
think
that
makes
more
sense,
I.
A
Think
it
will
make
sense
for
them
to
get
their
input
on
the
same
subject.
I
think
that's
very
interesting
because
I
mean
currently
we
are.
We
have
a
binding
towards
cloud
events,
but
we
could
bind
towards
other
types
of
envelopes,
so
whatever
message
or
even
other
kinds
of
interface
protocols
or
whatever,
as
well
but
currently
cloud
events,
we
we
are
dependent
on
cloud
events
right
now
and
our
current
binding
is
towards
tolerance.
B
Okay,
perfect
yeah,
in
that
case
I'll.
Take
that
take
this
github
issue
and
I'll
move
it
over
to
them.
I'll
link
back
to
this
github
issue
actually
and
just
see
what
they
say
and
then
you
know
maybe
maybe
next
sick
meeting.
We
can,
you
know
kind
of
like
elaborate
on
it
because,
like
I
said
like
this
is
a
big
enough
change,
where
I
want
to
have
the
right
discussions
in
place
and
take
the
necessary
time
to
make
sure
we're
making
the
best
decision
here-
and
I
think
that's
a
really
good
point.
C
So
it's
how
you
not
really
so
basically
cloud
events
is
basically
an
abstraction
layer
that
allows
you
to
if
you're
writing
an
application.
You
don't
want
to
to
decide
from
the
very
start
whether
you
you're
going
to
use
hdb
or
nuts
or
in
ptd
or
you
don't
want
to
be
like
fixed
on
a
specific
transport
layer.
It
basically
gives
you
the
abstraction
to
for
the
sdk
to
to
do
that.
C
D
To
send,
but
wouldn't
I
mean
the
way
I
see
this,
it's
basically
can
we
turn
something
that
is
not
a
cloud
event
into
a
cloud
event,
because
what
the
cd
event
thing
would
be
is
just
to
add
some
additional
data
to
it.
It's
it's
perhaps
more.
The
cloud
event
part
that
may
be
tricky,
or
at
least
that's
that's
part
of
the
trickiness.
D
So
so,
if
the
cloud
events
project
has
had
some
discussions
like
okay,
what
is
the
process
for
turning
an
existing
like
rest
response,
arrest,
request
into
a
cloud
event
or
to
also
be
a
cloud
event,
then
adding
the
the
data
yeah,
the
data
payload,
which
is
a
rather
small
thing,
I
hope,
would
be
adding
the
cd
events
payload.
I
should
say
the
seed
events.
Data
would
be
a
rather
small
extension
on
that,
just
adding
one
more
json
object
or
xml
object,
or
whatever
you
want
on
to
the
payload,
so
yeah.
B
Yeah
and
and
it
doesn't
hurt
to
get
their
input
regardless
right
so
sure
you
know
so
I
can.
I
can
definitely
just
reach
out
to
them,
be
like
hey,
I
don't
just
want
to
get
your
guys's
input,
you
know
and
see
what
they
say,
and
then
you
know
with
that
we
can.
We
can
definitely
iterate
and
see.
You
know
where
we
kind
of
sit,
if
that,
if
that
makes
sense.
C
B
B
B
Cases
and
okay,
awesome,
awesome,
yes
I'll,
be
here
two
weeks
from
now
and
then
another
thing
I
wanted
to
ask.
I
know
it's
already
late
for
you
guys,
but
would
it
be
possible
to
move
the
time
by
an
hour?
If
not
that's
completely
fine,
but
I
just
wanted
to
ask
because
one
of
my
co-workers
is
unfortunately
in
the
pacific
time
zone
and
that
it's
the
the
the
sig
meeting,
starts
at
eight
a.m.
And
unfortunately
that's
you
know
it's.
B
You
know
it's
it's
really
early
for
him,
but,
like
I
said
I
don't
want
to
you
know,
say:
oh,
you
know
move
the
time
you
know
but
like.
If,
if
that
isn't
an
issue
for
everyone,
then
I
would
be
you
know
I'd
be.
I
think
that
would
make
more
sense
for
for
people
that
are
especially
like
you
know
like
most
of
my
teams
in
in
in
california.
So
that
would
be
really
really
helpful,
but
if
not,
I
will
just
poke
them
at
8am
and
just
say:
hey.
D
A
A
Can,
of
course
discuss
it,
no
problem
depending
on
who
should
be
able
to
participate
on
the
meetings,
because,
of
course
we
want
to
to
have
everyone
on
board
that
should
be
here,
so
we
shouldn't
root
out
such
ideas,
it's
good
that
you
lift
it
so
far.
We
have
thought
that
this
is
the
best
time
slot,
but
if
we
get
more
people
from
pacific
sure,
we
should
discuss.
B
This
topic:
okay,
perfect,
perfect,
that
yeah,
that
sounds
that
sounds
great
and
I
already
knew
it
was
late
for
you
meal.
That's
why
I
asked
earlier,
but
I
you
know
I
I
just
figured
you
know
just
to
see
if
you
guys
have
discussed
it
but
yeah,
but
thank
you.
It
was
great
meeting
everyone
by
the
way
and
I'll
definitely
message
you
eric,
because
there's
a
few
things
I
wanted
to
talk
about
about
the
sdks
and
then
and
then
we
can
kind
of
go
from
there.