►
From YouTube: CNCF Serverless Working Group 2020-10-13
Description
CNCF Serverless Working Group 2020-10-13
E
Yeah
somehow
that
dialogue,
whether
I
want
to
join
with
my
computer
audio,
vanished
and
didn't
come
back.
E
G
Yeah,
my
my
heritage
is
norwegian
long
story
about
how
our
last
name
came
to
be
something
about
immigration
and
whatnot.
So,
okay,.
F
Okay,
thanks
for
having
me
because
manuel
speaks
german,
and
I
and
I
lived
in
germany
for
a
long
time-
and
I
didn't
know
if
we
could
talk
to
you
in
germany.
E
No,
no,
I
think
we're
still
leaving
some
time
for
people
to
join.
C
E
Yeah,
let's
get
started
so
community
question
time.
Are
there
any
questions
before
we
start.
E
If
not,
then
our
first
agenda
topic
is
kubecon,
which
is
approaching
fast,
and
we
have
a
lot
of
presence
there,
so
we
have
booked
office
hours
last
time.
We
already
had
these
two
slots
45
minutes
each
and
we
discussed
a
little
bit.
They
are
still
reschedulable,
but
I
think
by
now
all
the
slots
might
have
gone,
so
we
have
one
on
wednesday
10
a.m,
eastern
time
and
another
one
on
thursday
3
p.m.
E
I
think
it's
not
that
bad.
Given
that
the
event
starts
on
tuesday,
people
might
be
in
zero
day.
Collocated
events
and
friday
is
the
last
day.
So
a
lot
of
people
cannot
pay
attention
anymore,
so
having
these
two
slots
are
really
great,
also
wednesday
at
10
a.m.
That's
before
the
kino
talks
which
started
noon
and
then
the
thursday
one
yeah.
I
chose
that
because
anyways
this
is
going
to
be
a
busy
day
with
all
the
talks.
E
I
I
have
it.
I
have
a
talk
there,
and
so
I
selected
this
one
as
personal
preference.
Is
everybody
okay
with
these
slots,
or
should
we
go
and
look
if
we
find
another
one.
B
I
think
there
was
an
email
sent
today
that
today
is
the
last
day
to
pick
him,
so
let's
just
keep
them
for
now
to
not
lose
them.
Maybe
I
don't
know
unless
there
is
objection.
E
On
how
we
yeah,
we
should
all
be
there
right.
Why
not,
depending
on
how
what
we
wanna
put
in
there
so
for
kubecon
europe,
everybody
who
was
attending
these
office
hours
sort
of
was
expecting
something
to
be
presented.
E
There
were
only
a
few
that
I
saw
so
I
joined
a
few
project
discussions
and
a
few
actually
had
discussions
going
on,
but
mostly
it
was
one-way
presentation
and
yeah.
Maybe
we
can
redo
one
of
the
deep
dives
that
we
are
currently
planning.
Maybe
we
have
a
new
one
up
by
then
or
if
anybody
wants
to
present
something
in
the
project
pavilion,
please
feel
free
to
say
you
have
an
implementation
and
do
it
there.
E
I'm
taking
applications
until
coupon
and
the
next
point
is
the
project
boost.
So
here
it
would
be.
I
understand
a
little
bit
more
difficult
to
place
an
implementation
of
our
specification,
because
this
should
not
be
about
products.
E
B
C
C
It
is
to
say
we
don't
have
to
be
there
the
entire
time,
because
it's
pretty
much
the
whole
day
and
the
way
I
understood
it
is.
We
can
also
just
play
videos
like
that's
why
I
kind
of
went
this
weekend
and
created
some
videos
I'll
try
to
create
some
more
over
the
week.
Just
not
because
I
feel
like
you
know
there,
you
mostly
for
this,
because
then
we
can
send
them
links,
and
maybe
we
can
just
loop.
C
You
know
a
couple
of
videos
and
in
the
hours
where
nobody
can
be
there,
that
can
be
shown
you
know
to
to
to
people
interested,
but.
F
In
cuba,
I've
never
then
done
that.
So
this
is
news
for
me,
too.
C
Right,
no,
what
I
was
with
redhead
last
time
was
similar
to
what
we
did
for
the
project
office
hours,
but
basically
it
was
just
a
redhead
chat
channel
and
you
can
just
it
felt
weird
to
me
because
it's
almost
like
a
resume,
you
have
to
say
I'm
a
developer
and
so
and
so
am
I'm
working
on
this
and
that
and
then
whoever
is
interesting,
can
ask
you
questions
or
ping.
You
and
I
didn't
feel
like
advertising
myself
there,
because
I'm
just
not
into
that,
but
this
project
booth.
C
It
seems
that
it's
more
restrictive,
whereas,
like
at
the
same
in
the
in
the
project
office
hours,
we
can
say
who
we
are,
who
we
work
for
what
we're
planning
to
do
for
this
booth.
They
said
specifically,
we
cannot
like
do
any
sales
pitches
or
any
of
that
type
of
deal,
or
they
will
pretty
much
kick
us
out
forever.
C
E
I
think
I've
only
seen
one
or
two
booths
last
time.
Connectivity
to
the
integrator
website
was
really
bad.
So,
but
I
I
saw
yeah
a
video
showing
like
the
center
piece
of
the
webpage
and
that
may
have
changed.
I've
only
seen
one
or
two
videos,
but
I
think
that
was
a
main
advertisement
for
the
companies
and
they
had
a
twitter
feed
going
underneath
and
a
button
where
you
could
click.
If
you
wanted
to
talk
to
someone,
I
think
that's
all
there
is.
But
do
you
know
if
there
is
any
chat
that
we
have
to
staff.
C
C
That's
as
far
as
I
understand,
I'm
still
getting
there,
sorry
so
yeah.
So
I
need
to
be
able
to
log
in
right
now
they
only
gave
me
a
pass
and
then
I
need
to
add
five
members
of
the
set
from
the
team.
C
E
Okay,
then,
I
guess
we'd
be
setting
up
all
the
links
to
specification
sdks
a
little
bit
of
overview
loop,
the
videos
that
we
have,
I
think
we
should
probably
ping
doc
for
the
recording
of
our
last
community
call
two
weeks
ago,
if
it's
not
already
on
youtube
and
cut
out
our
deep
dive
if
you're.
Okay,
with
that,
tell
me.
C
E
C
But
for
for
you
mean
for
the
office
hours,
are
you
saying
I.
E
C
If
you
wish
the
introduction
slides,
I
have
that
we
did
last
time,
so
anybody
could
present
those
if
they
would
like
to
and
yeah.
Those
can
be
useful
too,
because
I
also
think,
like
I
agree
with
you
last
time
we
did
this.
I
think
a
lot
of
people
came
in
just
wanting
to
learn
what
this
is,
that
we're
doing
more
so
than
hearing
about
some
internal
discussions
about
some
specific
feature
that
might
be
over
their
head.
C
So
having
some
sort
of
introduction
at
the
beginning,
I
think,
is
useful
if
you
guys
agree,
yeah,
yeah
and,
and
I'm
still
not
done
with
slides
for
any
of
these
stocks.
Yet
so
I'll
tell.
E
Yeah
I
wanted
to
highlight
just
this
one
because
still
the
cloud
events
duck
and
clements
they
are
sort
of
where
we
came
from.
Please
add
them
to
your
schedule
and
then
we
have
teomiya
and
ricardo,
giving
a
talk
on
serverless
workflow,
here's
the
link
to
the
sketch,
you
can
add
it
to
your
calendar
and
also
the
serverless
working
group
lets
us
present,
serverless
workflow
again
and
yeah.
I
think
that's
that's
settled
right,
qma
you're,
going
to
do
that
with
doc.
E
E
E
E
And
yeah:
that's
about
it,
we
do
have.
I
didn't
copy
them
over,
but
we
do
have
from
our
second
last
community
call.
We
had
the
discussion
about
the
release
and
when
to
do
that-
and
this
is
approaching
fast,
so
our
next
community
colleges
wanted
to
remind
that
in
two
weeks
we
might
want
to
branch
out
and
freeze
with
what
we
currently
have
and
then
give
two
weeks
for
bug,
fixing
proof,
reading
and
so
on.
To
do
the
formal
release
of
1.0,
okay.
E
B
E
E
Okay,
so
I
think
we
might
even
be
able
to
do
a
decision
on
this
one.
There
were
a
few
changes
within
the
last
24
hours,
but
I
think
that
was
only
a
small
change.
How
long
is
this
thing.
E
So
in
the
meantime,
last
week
monday,
we
had
a
call
with
alex.
It
was
very
interesting.
I
think
everybody
was
on
the
call
right-
yeah,
okay,
okay,
okay
spare
the
time.
So
how
do
we
go
on
about
this
of
an
api?
Do
we
want
more
time
on
this?
Are
we
good
to
take
it
over
as
it
is
now.
D
C
Oh
yeah
yeah
sure
I
basically
I,
but
today's
remind
you
this
first
question.
No,
I
think
jurgen
needs
to.
We
need
to
come
to
an
agreement.
I
don't
think
I
can
push
these
changes
or
we
should
push
the
changes
without
him
being
okay
with
it,
because
he's
been
very
involved
in
this
from
the
start
and
has
some
very
good
ideas.
C
The
basic
thing
is
that
we
have
to
make
a
decision,
and-
and
this
decision
I
believe,
is
pretty
big-
I
think
functions
right
now-
not
to
bring
all
the
or
livestock
back
up
are
an
important
part
to
fix
for
one
o.
So
in
my
opinion,
this
is
a
little
bit
holding
up
the
1
0
milestone,
whatever
one
I
guess,
release,
because
it
it's
important
and
just
the
changes
that
I
had
to
answer
your
question
is
I
I
really
try
to
describe
exactly
that.
We
we
are
able
to
describe
everything
with
our
function
definition.
C
So
if
so,
if
you
have
service
that
you
want
to
invoke
that,
you
know
where
he
lives
and
you
have
information
about
where
the
runtime
needs
to
go.
To
invoke
it.
You
can
use
the
function
definitions,
but
the
only
thing
that
we
can,
we
can
would
you
say,
confirmed
that
is
probably
portable
across
different
run
times.
As
far
as
the
markup
goes
is
the
use
of
open
api
definition,
so
we're
offloading
that
part
off.
C
If
you
decide
to
use
a
custom
defined
custom
information
within
the
markup
in
the
function
definition
specifically,
we
cannot,
as
a
specification
guaranteed
that
your
workflow
definition
might
work
on
a
different
runtime
implementation.
So
that's
really
all
I
kind
of
tried,
in
my
best
english,
to
to
write
down
and
also
put
provide
more
examples
of
how
to
use
the
metadata
section
to
have
a
free
form
definition
that
makes
more
sense
for
people
that
they
don't
they
don't
want
to
or
don't
have
their
services
exposed
to
be
arrested.
C
Now
still
the
specification
allows
is
we
talked
about
and
also
open
a
different
pr
that
we
will
look
at
that.
I
think
is
also
very
interesting
for
event
based
invocation
of
services.
We
handle
that
separately.
C
So
this
only
is
really
the
function,
definitions
for
services
that
we
know
how
to
invoke,
specifically
not
for
things
triggered
by
events.
D
G
D
C
C
The
the
difference
is:
is
that
what
we
have
event
definition
to
describe
events
that
are
either
consumed
or
produced,
and
we
can
already
produce
events
in
transitions
at
workflow
and
definitions
and
things
like
that,
the
same
approach
we're
taking
for
actions
where
we
say
look,
I
want
to
produce
an
event,
but
in
order
to
produce
an
event,
we
need
to
keep
it
consistent
by
just
referencing
it.
We
reference
an
event,
definition
in
transitions.
We
reference
an
event,
definition
on
the
end
definition
to
produce
an
event.
C
So
in
order
to
keep
it
consistent,
the
actions
do
the
same
function.
Definition
does
not
mean
execution
of
a
service;
it
just
means
a
description
or
invocation
of
something
that
we
want
to
invoke,
but
the
actual
action
itself
we
divided
it
and
from
the
market
perspective,
I'm
not
arguing
with
you
you're
again.
I
think
there
could
be
improvement
there
in
order
to
make
it
specific,
but
I'm
just
saying
like
the
idea
of
actually
moving
that
into
a
function,
definition
itself,
that's
what
I'm
kind
of
like.
I
don't
know
about
that.
Well,
so
the.
G
Maybe
I
mean
what
I
had
imagined:
it
would
be
a
function
that
would
reference
two
event
like
basically
look
the
same
as
the
events,
a
camera
one's
called
in
the
actions
section.
But
you
know
it's
still
referenced
to
events.
It
wouldn't
be
like
defining
them
in
line
in
the
function.
C
That's
a
good
idea.
The
only
thing
that
I
have
issue.
I
cannot
have
an
issue
with,
but
maybe
more
I'm
asking
is:
does
he
really
fit
in
there,
because
sending
out
an
event
can
really
trigger
a
set
of
services?
So
it
wouldn't
be
a
function
definition.
It
would
be
or
a
service
definition,
whereas
in
a
function
each
of
the
definitions
in
the
functions
array
really
represent
a
single
service
in
its
operation,
whereas
triggering
an
event
can
actually
invoke
invocation
of
15
200
services
and
they
might
not
be
even
services
might
be
other.
C
You
know
workflows,
it
might
be
triggering
whatever
you
know
is
actually
listening
for
this
types
of
event.
It
can
even
trigger
an
argo
workflow
or
trigger
a
pipeline
execution.
In
this
case,
yeah.
D
C
That
that
is
why
my
confusion
is
like
if
we
add
that
in
there
are
we
confusing
people
as
far
as
what
a
function
definition
means
and-
and
so
we
can
definitely
talk
about
it.
I
think
that's
a
it's
a
very
good.
You
know,
and
I
I
agree
in
some
way-
maybe
finding
a
way
to
kind
of
put
this
together
makes
sense,
but
how
you
know
it's.
Maybe
we
can
do
some
examples
and
and
talk
about
it.
G
Yeah
I'd
like
to
explore
that
I
think
there's
ways
to
make
it.
You
know
I
think,
as
a
as
a
consumer
of
a
workflow.
I
just
want
to
whether
it's
you
know
a
whole
thing,
slew
of
services
that
listen
for
that
event
and
respond,
or
it's
one
thing,
I'm
still
kind
of
trying
to
kick
off
invoke
something
right,
and
so
I
don't
really
want
to
know
the
details.
I
just
want
to
know
that
how
to
invoke
it
and
what
to
wait
for
at
the
end
right.
G
So
it's
you
know
it
seems
like
that's
easier
for
people
to
think
about.
If
it
just
feels
like
I'm
invoking
something
I
I'd
I'd
love
to
explore
it
more.
You
know
like
we
can
go
through
some
examples,
maybe
just
to
kick
around
the
idea,
and
that,
in
that
issue
that
I
filed
is
that
what
you're
thinking.
C
That's,
I
think,
the
best
approach,
one
of
the
things
I
found
was
like
once
we
started
actually
doing
examples
and
seeing
the
json
or
the
ammo,
then
it
kind
of
clicks.
You
know,
and
it's
like
wow.
This
is
two
verbose
or
oh
wow.
This
makes
actually
no
sense
whatsoever
and
having
these
types
of
iterations,
I
think,
would
really
help
to
nail
this
down
to
be
better
than
what
it
is
now
and
I
I
agree
it's
not
perfect,
but
at
the
same
time
it's
not
bad
either
so
yeah
yeah.
C
G
Well,
it
seems
to
me
like
this:
is
I
mean
it
seems
like
we
can
resolve
this
pr,
and
then
you
know
to
do
a
separate
discussion
about
the
actions
thing
and
you
know
maybe
that
changes
this
pr
a
little
bit,
but
it
doesn't
seem
like
we
should
block
this
pr.
For
that.
C
Right
yeah,
thank
you
and,
I
think
also
for
pubecon.
You
know
having
like
this
little
bang
of
a
milestone.
One
release,
I
think,
would
be
very
beneficial
and
knowing
that
yes,
we're
not
perfect,
and
yes,
we
got
tons
of
improvements
to
make
in
the
near
and
far
future,
and
it
will
do
it
in
the
in
the
milestones
to
come.
Is
there
something
that
is
okay?
Also,
here
again.
G
D
My
feedback
around
that
would
be.
Does
it
need
to
be
1.0,
for
example?
The
questions
I
am
asking
myself
is:
what
is
the
in
the
cncf
community?
What
is
the
general
perception
if
you
need
to
do
a
breaking
change
from
1.0
and
then
the
second
question
I'm
asking
myself
is
like?
Should
it
be
1.0
or
like
another
milestone?
That
is
less
than
1.0
like?
Are
we?
What
are
we
trying
to
convey
with
1.0?
C
Yeah
and
they're
all
valid
questions,
and
I
get
it,
but
the
problem
we've
been
around
like
we
have
been
just
accepted,
what,
in
june
or
july,
for
sandbox
project
and
and
one
of
the
things,
maybe
that
is
that
I
wanted
to
convey
with
this
is
more
pr
move.
More
than
anything,
we
know
that
we
need
a
lot
of
improvement.
C
We
have
been
doing
improvements
for
a
long
time
now,
but
still
a
lot
is
to
come,
and-
and
this
is
where
you
know
you
guys
come
in-
and
everybody
from
the
community.
So
the
point
of
improvement,
continuous
improvement
is
always
going
to
be
there.
As
far
as
stability
goes.
My
question
goes
back
is
like:
when
do
we
say
we're
stable
at
some?
C
That
section
really
needs
to
be
improved
and
I've
been
kind
of
trying
to
get
that
done
whenever
I
can,
but
I
haven't
been
successful
yet
to
cook
finish
so
the
only
thing
for
kubecon
now
is:
we
have
to
figure
out,
because
we
already
had
talks
at
last
cubecom.
We
were
0.2
now
if
we
are
still
0.2,
they
might
look
a
little
bit
like
we're
not
doing
anything
or
not
doing
any
incremental
improvements.
C
Basically,
the
only
thing
is
question
is
how
do
we?
How
do
we
co,
show
people
that
we
are
continuously
moving
forward,
but
at
the
same
time,
keeping
this
notion
that
you're
saying
is
hey?
Are
we
stable?
Can
we
be
used
because
we
I
already
work?
I've
been
working
on
two
runtimes
now
for
this,
both
java
based
and
it
works,
you
know.
So
what
does
table
really
mean?
I
don't
know
it's
more
of
a
decision
by
our
team.
Then
I
think
the
perception
of
anything
else.
I
don't
know.
D
No,
no
definitely
I
get
the
pr
perspective
and
the
need
to
show
that
we're
making
progress
the
only
yeah,
that's
the
question
I
have
is:
should
it
be
0.3,
0.5
or
straight
1.0,
right.
C
And
not
really
clear
as
long
as
I
can
say
in
you
know
like
when
we
introduce
our
specification,
we
can
say
hey.
We
just
released
the
version
x
point
y
and
I
really
don't
care
what
it
is
honestly
as
long
as
as
long
as
there
is
something
that
we
can
say.
You
know,
because
the
the
bigger
problem
also
and
also
manual,
you
know
this.
Our
0.2
release
is
actually
in
our
old
github
repository.
C
So
in
the
current
one
that
we
are
at,
we
actually
have
no
releases
yet,
and
that
would
also
help
with
that
where
we
can
actually
remove
the
0.2
completely
because
it
really
is
kind
of
like
we've
done
so
many
improvements.
C
After
that,
I
don't
think
it's
even
relevant
that
there
is
no
runtime
or
anybody
actually
using
that
old
version,
not
remove
it,
but
maybe
just
push
it
somewhere,
where
it's
kind
of
hidden,
maybe
a
little
bit,
because
we
don't
want
people
to
go
to
the
old
repository
you
know
and
and
to
just
have
a
release
on
ours
which,
before
we
also
only
had
a
release
of
the
specification
schemas.
But
now
we
also
have
the
java
sdk.
The
go
sdk,
the
visual
studio
code,
plug-in
and
all
of
those
places.
E
So
there
are
several
definitions
of
what
a
1.0
release
marks.
One
I
found
was
that
people
think
it's
sort
of
complete
in
a
way
that
it
has
all
the
aspects
covered.
It's
not
like
imperfect,
but
in
completeness
and
that
it
is
usable-
and
I
think
we
are
already
past
this
usable,
so
I'm
okay
with
going
to
higher
versions,
but
it's
also
different
teams
develop
different
cultures.
If
you
take
canadian,
for
example,
they
are
still
in
the
zero
dot,
but
they
are
being
used
a
lot
in
in
other
projects.
E
So
I
really
think
if
we,
if
we
do
a
major
release
here,
that's
something
where
you
can
then
later
safely.
Do
implementation
on
sdks,
of
course,
until
the
next
major
release,
but
for
a
while
this
will
be
the
the
standard
being
used
in
implementations
and
then
whatever
the
next
release
brings,
can
be
rolled
out
at
a
later
stage.
So
having
this
state
captured
in
a
major
release
version
to
me,
it
makes
sense.
I
personally
when
I
started,
I
had
doubts
about
everything
like
if
states
should
be
the
right
thing
to
use.
E
You
know
other
projects
use
like
tasks
pipelines
they
originate
from
ci,
cd
pipelines
and
so
on.
There
are
direct
acyclic
graphs
and
all
sorts
of
things
whether
we
should
really
have
these
states
was
unclear
to
me,
but
now
that
we
have
also
covered
the
how
to
invoke
a
function
for
the
first
time,
we
have
somehow
settled
on
this,
the
http
binding
being
something
that
we
would
want
to
see
supported.
E
We
have
the
json
and
yaml
formats
for
everything,
and
we
have
cloud
events
not
just
saying
like
oh
yeah,
it
will
be
cloud
events
someday,
but
actually
using
cloud
events
in
the
specification
to
me.
That's
pretty
good,
pretty
good
state
right
now.
C
Yeah
yeah
and
in
addition
you
know
with
the
addition
of
the
sdks
and
the
visual
studio
code,
plug
it's
all
specification
based
and
that's
important.
You
don't
have
to
go
out
and
download
some.
You
know
companies
extension
in
order
to
use
it.
You
download
the
serverless
workflow
specification
extension,
you
know
and,
and
I
think
we're
getting
somewhere
is
just
growing
the
community
and
actually
changing
our
processes,
giving
the
number
of
people.
C
You
know
that
we
have
and-
and
I
hope
one
day
we
will-
you
know-
become
like
where
we
get
like
cloud
events,
50
people
in
a
meeting
and
we
have
takes
like
a
month
to
do
a
single
pr.
I
would
love
that
as
well.
You
know,
and
but
it
is
what
it
is
at
this
time
and
we
just
have
to
push
forward
and
I
think
we
have
the
ability
with
a
smaller
community
and
people.
C
You
know
great
people
like
on
this
call
and
and
the
others
they're
joining
to
to
to
really
do
something
about
this.
But
yeah,
please,
you
know,
keep
patient
with
us
and-
and
just
you
know,
let's
see
if
we
can
together
move
this
forward,
because
at
the
end
I
think
we
will
all
have
success.
Some
sort
of
success
with.
I
hope,
let's
see.
E
About
this
function,
ref
and
event
draft
yeah,
maybe
we
can
speed
things
up
a
little,
so
the
one
thing
is
whether
we
allow
the
pr
now
or
keep
working
on
the
pr
and
merge
it
later
or
if
we
merge
it
now
and
then
make
an
additional
pr
on
top
of
it,
I'm
very
much
in
favor
actually
of
collapsing
event
draft
and
function
ref
into
just
function
graph,
because
the
way
event
draft
is
specified
now
with
the
trigger
and
result.
E
That's
a
message
going
out
and
a
message
coming
in
very
much
like
a
function
call
so
in
a
function
call.
You
also
only
know
the
function
signature.
You
know
what
to
send
out
the
event
specification,
like
the
event
type,
also
tells
you
what
to
send
out.
So
in
that
case
the
trigger
and
making
the
function
call
is
similar,
and
what
you
get
back
is
sure
in
a
swagger
definition
would
be
defined.
E
E
So
maybe
there
is
even
more
than
one
possible
result
in
here
and
having
this
as
a
function.
Definition
really
makes
sense
to
me.
It
also
tidies
up
the
actions
right.
You
only
need
the
function
reference
and
don't
have
these
complicated
rules
of
if
there
is
a
functional
reference
in
there
or
an
event
reference
in
there.
G
I
agree
once
I
think
those
are
good
points
it
seems
like
maybe
since
teomir
you
wanted
me
to
you,
wanted
to
get
my
input
on
the
pr.
G
Maybe
give
me
a
chance
to
look
at
that,
and
I
can
add
a
comment
you
know
I
I
just
want
to
look
through
it
real
quick,
but
I'm
sure
it's
I'm
sure
it's
all
good.
We
can
close
that
and
then
we
can
move
on
to.
You
know,
discuss
more
of
this
events
and
function
thing
in
the
in
the
issue.
For
that.
C
With
the
other
issues
that
we
will
take,
you
have
open,
especially
around
the
retries
and
the
air
handling.
I
think
that
that
will
be
huge
if
you
can
help
me
out
with
that
sure.
What
do
you
mean
by
help
like
I,
I
just
nothing.
I
don't
expect
just
comment
some.
I
will
do
some
pr's
link
him
to
your
issues.
C
G
Yeah,
I
would
love
to
take
a
look
at
that
I'll
I'll
keep
an
eye
out
for
those
and
review
him
as
soon
as
I
see
him
thanks.
I
appreciate
you
integrating
the
feedback.
E
Okay
cool:
should
we
go
to
the
first
of
those
issues?
Is
it
in
the
right
order?
No
there's
another
one.
E
That's
the
one
we
already
just
discussed
yeah
so
in
the
next
logically,
yeah
jason,
patchy.
C
Ricardo
from
the
standard
called
jsonpatch,
which
allows
you
to
define,
commands
on
how
to
change
the
json
data,
since
all
our
states
that
or
the
workflow
data
is
in
json,
he
said
it
would
be
a
nice
thing
to
use
a
standard
instead
of
defining
some
custom
modifications
of
of
the
data
using
some
other
languages,
which
makes
sense.
C
G
I
don't
know
much
about
jason
patch.
The
thing
that
worries
me
about,
like
it
sounds,
sounds
cool,
but
hopefully
it's
not
touring
complete.
Is
it.
B
E
Yeah
one
thing
I
know
for
sure
is
that
customized
can
be
really
a
pain,
especially
using
jason
patches,
but
maybe
that's
sort
of
their
adoption
of
the
rfc.
The
rfc
is
sound.
It's
it
needs
a
little
give
me
a
little
bit
of
experience
with
it
until
you
can
use
it
in
production,
but
yeah.
E
So
all
data
we
handle
workflow
data
that
we
juggle
in
in
states.
They
should
all
be
json
addressable
or
don't.
We
have
the
also
the
the
yaml
format.
C
The
data
itself
is
always
json
and
what
he's
kind
of
talking
about
I've
run
into
it
and
if
you
guys
have
just
a
minute
to
just
explain
the
issue
itself
is
on
the
runtime
implementations,
for
example,
our
inject
state,
you
have
state
data,
and
the
inject
state
gives
you
a
json
object,
which
then
you
have
to
merge
with
the
state
data.
The
same
thing
is
really
also
on
all
our
data.
C
Formatting,
we
get
a
a
response
from
a
function,
call
or
or
an
event
that
comes
in,
has
its
payload,
and
we
have
to
take
this
payload
and
do
something
with
it
in
order
to
merge
it
with
the
state
data
itself
and
jsonpatch
what
it
helps
in
there
is
right
now
the
way
I
have
to
do
it.
I
have
to
basically
use
either
the
the
underlying,
in
my
case,
java
json
apis
in
order
to
merge
stuff
together
and
it's
kind
of
complicated
at
times.
C
C
E
Yeah,
I
know
that
we
usually
use
adjacent
past
to
define
where
we
want
the
result
of
a
function
to
end
up
these
add
delete
operations
in
json
patch.
E
They
can
be
used
as
a
script
to
make
more
complex
modifications
of
of
a
json
structure,
and
I'm
wondering
if
that
is
sound
in
in
the
markup
that
we're
using.
So
it
might
blow
up
our
workflow
definition
a
little,
and
I
am,
I
have
to
think
about
it-
yeah.
E
E
Okay,
then,
the
next
one
uniqueness
constraint
for
workflows.
G
Yeah,
so
the
background
on
this
is
that
I
think
a
common
feature
for
people
who
want
to
implement
workflows.
Is
they
want
kind
of
a
logical
single
instance?
Like
say,
I've
got
a
compute
resources
that
I
want
to
repair.
I
don't
want
to
run
that
repair
job
three
times.
I
want
to
run
it
once
and
if
the
workflow
engine
can
enforce
that
uniqueness,
it
makes
things
easier
for
people
using
workflows,
and
I
see
a
parallel
in
of
this
in
the
event
correlation.
G
I
can
actually
accomplish
this
with
event
triggered
workflows,
because
the
correlation
rules,
as
far
as
I
understand
them,
allow
for
this,
but
it
doesn't
work
well
for
directly
invoked
workflows
and
it
doesn't
or
it
doesn't,
that
doesn't
exist
for
directly
in
both
workflows
and
it
doesn't
exist
for
the
like
cron
scheduled
workflows,
and
so
you
know
I
was
trying
to
figure
out
how,
if
there's
a
way
that
we
could
get
that
uniqueness
constraint,
that
we
have
for
event
invoked
workflows
to
work
for
the
other
two.
G
So
maybe
that
means
I
don't
know
exactly
what
that
means
in
terms
because
I'm
still,
you
know
getting
familiar
with
the
spec,
but
in
my
mind
you
know.
That
means
something
about
like
changing
the
way
the
correlation
rules,
work
or
making
them
like
pulling
that
up
a
level.
So
that
applies
to
all
three
of
those
or
you
know,
there's
more
of
a
hey.
This
is
a
really
useful
feature
in
a
workflow
engine
and
asking
you
know
for
ideas
on
how
we
could
what
we
could
propose.
C
Is
very
interesting
and
I
I
think
we
should
definitely
explore
it
further
if
we
get
it
if
we
nail
it
down,
I
think,
like
you
said
it
is
very,
very
good
to
have
because,
like
another
thing
to
look
at
is
like,
like
aws,
for
example,
has
an
additional
information
you
can
give
to
workloads
even
like
restrictions
on
what
region
can
execute
it
or
what
we
can
even
execute
to
a
task
within
a
workflow
user
restrictions
based
on
roles
and
and
blah
blah
blah.
C
We
don't
have
that
currently,
so
this
is
important
start
to
start
introducing
not
only
the
markup
as
far
as
the
logical
execution
goes,
but
also
in
addition,
provide
runtimes
to
information,
because
in
the
end,
what
you're
saying
what
we
have
to
be
concerned
of
and
kind
of
careful
is
that
we
allow
users
to
solve
business
problems
at
the
end.
You
know-
and
I
believe
I
didn't
get
your
your
idea,
but
then
then
I
thought
about
it
and
it
said
being
able
to
execute
a
workflow
only
once
it's
actually
a
business
decision.
C
G
Like
if
you
imagine
going
from
one
runtime
that
does
support
this
uniqueness
and
going
to
another,
I
would
have
to
rewrite
my
workflows
to
do.
You
know
potentially
do
that
kind
of
you
constraint
on
their
own
in
their
business
logic
or
something
right,
so
it
wouldn't
my
if
one
runtime
supports
and
others
don't
you
know
it's.
G
C
Yeah
and
and
then
addressing
the
the
the
cloud
events
correlation
rules.
I
think
it's
we
if
we
can
go
with
that
approach,
to
define
correlation
rules,
maybe
between
workflows
and
and
and
states
within
the
workflows.
I
think
that
would
maybe
that's
the
right
approach
right
now,
but
yeah.
Let's,
let's
move
this
forward
and
and
and
add
to
it,
as
as
we
have
ideas,
okay,.
G
Okay,
so
maybe
I'll
I'll
think
of
some
suggestions
on
ideas
and
and
just
kind
of
throw
out
some
ideas
and
we
can
go
from
there
or
what
do
you
think
on.
B
E
E
What
is
it
the
workflow
event
definitions,
but
one
thing
I
was
wondering
the
correlation
token
we're
currently
using
using
that's
something,
that's
in
any
payload
that
triggers
a
workflow
right
and
doesn't
this
the
spec
say
that
if
that
token
is
the
same,
we
should
end
up
in
the
same
workflow
instance.
C
Yeah
that
that
event-
and
I
think
jorgen
is
looking
for
like
cron
job
triggered
work,
so
anything
like
that
doesn't
have
that
doesn't
have
an
event.
I
think
we
covered
like
cloud
events
allows
us
to
cover
that
part
with
correlation
on
the
on
the
events
and
and
their
context
properties.
C
But
if
we're
just
starting
workflow
without
an
event,
I
think
jurgen
is
trying
to
figure
out
how
to
correlate
these
types
of
workflow
instances,
especially
like
what
he
said
with
the
with
the
cron
job
execution.
G
E
Don't
be
afraid
to
suggest
something
that
would
even
change
the
spec
so
far,
we're
not
looking
for
backward
compatibility
if
that's
the
better
way
or
unifying
things
for
the
workflow.
That's
it's
also
an
option.
G
Okay,
yeah,
okay
I'll
try
to
just
kind
of
propose
some
ideas
and
point
out
where
it
causes
problems
with
existing
stuff,
and
maybe
we
can
run
from
there.
E
E
F
C
But
just
overall
bonus
the
the
thing
that
one
of
the
sections
that
we
really
need
to
approve
it.
I've
been
kind
of
trying
to
do
it
myself,
but
now,
with
jurgen's
comments,
it's
gotten
bigger
than
what
initially
is
the
error
handling.
C
E
Yeah
one
way
to
look
at
it
from
protocol
design
is
also
like
when
you
take,
for
example,
the
the
tcp
stack
for
something
where
you
cannot
even
reach
your
counterpart.
The
connect
failing
what
you
get
is
a
specified
response
so
to
the
application
level.
It
looks
like
it.
It's
getting
a
response,
even
though
the
call
wasn't
even
made
so
for
functions
and
error
handling
what
we
we
could
look
at
this.
Similarly
saying
that
we
do
make
the
function
call
but
not
being
able
to
locate
the
function.
E
E
If
we
want
to
design
it
that
way,
and
then
the
user
can
decide
whether
to
use
that,
even
as
in
a
good
weather
case
like
I
before
when
I
mentioned
the
404,
not
fine,
not
found,
maybe
that's
a
an
expected
response
or
to
yeah
having
a
non-treated
response,
which
will
throws
general
exception
or
means
we
have
a
default
error,
handling
or
specified
error
handling.
G
That's
actually,
especially
the
404,
if
you
think
about
workflows
needing
to
be
generally,
when
you
design
workflows,
they
need
to
be
very
important,
and
so,
if
I'm
deleting
resources,
404
is
a
response
I
have
to
handle
as
success
in
the
delete
case,
because
I
might
have
already
tried
to
delete
and
succeeded,
but
I
didn't
get
a.
I
got
a
network
error
back
instead
of
a
success
right,
so
my
next
attempt
would
be
a
404,
and
that
should
be
a
success.
E
Why
do
we
have
it
twice?
This
is
137
and
this
one's
36.
E
D
E
Specify
these
intervals
and
if
it
was
a
one-shot
time
so
to
say
that.
E
G
E
E
C
B
A
E
So
anybody
in
favor
or
against
having
it
next
another
call
in
between,
because
our
next
call
would
be
in
two
weeks
and
that's
already
our
second
class
before
con.
E
G
Seems
reasonable
to
me,
you
know
just
so
chat
wise.
We
can
follow
up
on
what
we
just
discussed
and
next
time
this
time
next
monday
works
for
me.
E
Okay,
perfect.
Thank
you
very
much
then
read
you
later
and
see
you
next
monday.