►
From YouTube: CNCF Serverless Working Group 2020-11-25
Description
CNCF Serverless Working Group 2020-11-25
A
D
D
D
D
D
D
B
B
All
right,
yeah,
we
just
we
just
more
or
less
started
this
week
to
have
a
look
at
this
stuff
looks
interesting.
There
were
a
couple
of
questions
yeah
than
the
golang
sdk.
We
found
a
couple
of
issues
we
raised
so
far
and
yeah,
but
if
the
general
questions
are
going
into
github
as
well,
then
we're
just
doing
it
that
way.
Okay,.
D
Okay,
so
kubecon
call
for
papers
is
up.
I
think
there
are
two
weeks
left
if
anybody
wants
to
send
in
their
application
for
cubecontalk
and
then
website
update,
I'm
not
sure
if
we
have
collected
any
feedback
so
far.
If
so,
they
would
have
appeared
here
in
the
issues
right
now.
There
is
no
the
ongoing
one
that
was
the
move
to
netlify.
D
A
No,
I
haven't
sorry,
I
I
no
never
mind
the
domain
like
serverless
workflow,
I
mean
the
email
serverless
workflow
at
gmail.com
and
I
happily
share
would
share
that
and
then
we
could
use
that
to
create
a
youtube
channel.
We
could
create
a
community
password.
You
know
for
for
people
that
want
to
maintain
it
so
yeah,
not
nothing
from
karina
but
yeah,
but
that
will
be
really
nice
to
do.
I
agree.
E
D
D
A
D
D
A
A
A
Yeah,
if
you
want
to
so
recently,
we
have
added
or
updated
the
air
handling
and
the
retries
and
I've
created
that
video
demo
and
we
can
link
it
yeah.
You
can
click
on
that
link.
You
can
see
that
better,
so
error,
handling
and
retries
is
per
state,
but
we
also
compensation
deals
with
like
this
does
undoing
or
reverting
the
work
that
has
been
performed
by
a
number
of
states
and
has
been
successfully
performed.
A
A
Compensations
can
be
triggered
by
either
transitions
or
end
definitions,
and
there
are
some
rules
about
states.
They
are
compensating
states
and
stuff
like
that,
all
in
the
pr
as
well.
If
you
look
down,
there
are
some
images
as
well
that
describe
how
compensation
should
be
executed
and
things
like
that.
D
A
If
you
go
down,
you
look
at
the
pictures,
I
think
you'd
clear
more
down
down.
So,
let's
a
little
more
down.
Sorry
all
right!
So
let's
take
a
look
at
this
picture.
This
kind
of
describes
it.
If
you
we
want
to
talk
about
it,
so
a
workflow
has
its
control
flow
logic.
This
is
shown
by
the
blue
states
and
the
start
and
the
end
definitions.
A
A
A
I
need
to
update
the
pr
sorry
and
at
which
point
we
want
to
compensate
the
already
completed
states,
which
means
we
go
in
reverse
order
and
we
first
are
going
to
see
the
e
state
which
does
not
define
its
compensation,
so
we
doesn't
need
to
be
compensated.
We
go
to
d
and
he
has
one
state
which
is
meant
for
compensation,
so
that
will
be
executed.
Then
we
go
to
b,
which
has
defined
two
compensation
states
and
then
a
does
and
c,
even
though
he
does
define
a
compensation.
A
A
You
know
the
states
as
as
you
would
completed
any
then
the
gray
ones
are
the
ones
they're
compensated
in
reverse
order
and
after
compensation
is
done,
we
continue
either
if
it's
defined
via
transition
to
to
execute
the
transition
or
if
it's
defined
in
an
end,
definition
to
end
workflow
execution
does
the
help,
and
I
know
it's
it's
a
kind
of
hard
concept
and
it's
it's
it's
pretty
complex
at
times
or
can
be,
but
it's
actually
pretty
simple,
so
I'll
give
you
guys
time
to
look
at
it
and
think
about
it.
So.
C
Yeah
sorry,
so
how
was
how
are
the
states
defined?
Maybe
you
went
through
that,
but
let's
say
that
if
you
go
through
the
states,
what
is
the
deciding
state
if
you
apply
for
all
the
compensation,
is
there
a
sequence
in
which
we
define
the
compensation?
If
something
fades,
do
we
retry
doing
a
competition.
A
A
The
error
handling
is
in
serverless
workflow
per
state,
so
it's
each
state
defines
its
own
air
handling
and
retries
compensation
is
more
on
overall
workflow
level,
where
you
want
to
undo
what
has
been
done
in
some
cases.
So
it's
a
business
logic
decision
not
triggered
by
events
or
data.
So
it's
not
a
dynamic.
You
have
to
specifically
say
that,
based
on
your
full
control
flow
logic
in
your
your
execution.
At
this
point,
you
want
to
actually
treat
your
compensation,
so
it's
kind
of
related,
but
not
really
too
early.
A
D
D
D
The
error
handling
and
requires
for
service
calls,
which
is
the
the
next
bullet
point,
I'd
really
like
to
do
that
today.
Right
now,
I'm
not
sure
if
we
should
discuss
incubation
before
or
after
I
just
put
the
I
mean
this
is
an
ongoing
topic,
so
maybe
the
only
thing
I
added
was
the
link
to
the
graduation
criteria
and
then
before
we
apply,
I
think
we
have
to
check
those
and
then
yeah.
So
this
is
ongoing
and
then
yeah.
We
can
actually
do
that.
I
I'd
love
to.
I
also.
D
A
A
Small
changes,
I
I
put
the
some
small
wording
and
yeah
I
added
the
comm.
This
is
just
an
ordering,
so
people
see
our
community
select
channel
first
in
the
list
of
communication
and
then,
instead
of
contributors
support
community
contributor,
there's
made
the
wording
a
tiny
bit
better
and
I
put
the
independent
group
first,
not
because
they're
more
important
or
not,
but
to
show
community
that,
yes,
you
do
not
have
to
be
associated
with
a
company.
If
you
want
to
contribute
to
our
project,
so
just
show
up
front
hey.
D
D
D
A
Yeah,
I
need
to
update
it.
Ricardo
found
some
problem
with
an
image,
so,
if
yeah
other
than
that,
it's
just
the
same
example
we're
gonna.
Look
at
that
today
too,
it's
the
patient
onboarding
thing
and
he
made
sense
to
add
it
in
our
examples
as
well.
I
think,
for
the
future,
what
we're
going
to
start
doing
is
is
for
each
of
our
examples
and
we'll
talk
about
it
in
the
future,
have
actually
a
run,
maybe
not
part
of
the
specification
itself,
but
have
a
link
to
an
image
which
is
an
executable.
A
A
A
D
D
Okay,
this
I'm
going
and
we'll
leave
it
a
little
bit
more
time
because
it's
a
spec
change.
It's
not
just
contributors
on
the
examples
page.
So
this
is
yeah
needs
a
little
bit
more
time.
I
agree.
Okay,
then
we
are
through
with
the
prs.
So
we
have
the
demo,
then
the
the
deep
dive.
Sorry,
the
hands-on
error,
handling
and
retries
for
service
calls.
A
E
A
D
A
The
idea
is
for
every
example
that
we
have
so
we
don't
want
to
just
have
examples
that
are
like
yeah
just
there,
this
text
in
the
future,
for
every
single
one
of
our
examples.
We
wanted
to
have
an
image
built
for
it
that
you
can
deploy
and
run
easily
make
sense.
That's
a
good
idea.
I
think
that
would
help
the
community
yeah
and
make
us
more
look
viable
than
just
throwing
out
some
jason
at
people.
You
know.
D
A
All
right,
you
guys
see
this
screen,
I
guess
yeah
but
anyway.
So
so
what
I
wanted
to
show
is
recently
we
updated
before
version
0.5,
release,
error
handling
and
we
also
added
retries.
Now
jurgen
here
is
a
you
know,
and
others
are
also
working
on
adding
more
stuff
to
retries
and
stuff
like
that
more
parameters,
so
that
updates
are
coming
hopefully,
and
but
this
is
just
what
we
ended
up
doing.
Is
we
revamped
error,
handling
and
and
retries
to
make
sense,
and
this
is
just
an
example.
A
A
So
the
way
in
this
demo
that
I've
been
kind
of
using
it
does
we
have
an
event
state
so
in
in
serverless
workflow,
when
you
define
stages
for
people
they
might
be
new,
each
state
has
a
type.
We
currently
have
nine
different
state
types
and
if
you
guys
see
the
kubecon
presentation,
I
don't
know
but
long
story
short
state
is
basically
we
do
explicit
control
for
logic
in
serverless
workflow,
where
we
define
with
the
type
units
know
exactly
what
type
of
control
for
logic
you're
dealing
with.
A
So
if
we
have
an
event
state
just
but
just
looking
at
it,
you
know
you're
dealing
with
events
and
something
consuming
events
in
this
case
and
performing
some
actions.
So
long
story
short.
This
starts
thing:
I'm
just
gonna
go
for
people
that
might
be
new.
The
star
definition.
Each
state
can
say,
define
a
start
definition,
which
means
it's.
This
first
state
that
is
executed.
A
When
workflow
instance
is
created
in
case
of
event
states,
however,
there
are
also
starting
states.
Workflow
instances
are
actually
created
on
arrival
or
consuming
of
a
new
event,
so
when
event
of
new
patient
event
is
consumed
right,
this
is
a
logical
name.
You
have
your
event
definitions
below.
If
you
have
questions
on
that.
A
Let
me
know
so
in
this
case,
we're
saying
when
a
new
patient
event
is
received,
a
workflow
instance
is
going
to
be
created
and
this
state
is
going
to
perform
three
actions
in
serverless,
workflow
and
action
corresponds
to
an
invocation
of
a
distributed
service.
For
that
we
see
here
either
can
be
done
sequentially
or
in
parallel.
The
default
for
action
execution
is
sequential,
so
we
don't
have
to
particularly
define
it
here,
but
you
can
define
an
action
mode
here
if
you
want
to
do
it
in
parallel,
the
default
is
a
sequential.
A
We
have
to
store
the
new
patient,
assign
a
doctor,
a
schedule
appointment,
and
if
you
look
at
some
of
our
other
videos
and
stuff,
you
will
see
that
we
use
the
open
api
specification
for
rest
full
service
invocation.
So
we
have
we
reference
I'll
show
you
guys
here
in
the
function
definition
the
path
to
the
actual
open,
api,
json
or
yaml.
If
you
have,
that
is
fine
and
the
unique
operation
id
of
that
particular
operation
of
the
function
needs
to
be
now.
That
was
the
first
demo.
So
I
would
fire
up.
A
E
A
Initially,
we've
added
things
like
event
state,
we
added
a
callback
state,
we
added
a
switch
state
and
things
like
that
from
you
know.
So,
as
we
involved
the
specification
to
version
0.5,
it
added
more
control
logic
blocks
that
can
be
expressed.
We
had
our
language,
we
added
more
states,
so
there
is
not
a
set
number
of
states
in
the
future.
If
we
find
that
there
is
a
particular
control
for
logic
thing
that
we
are
not
covering
by
the
language,
you
can
definitely
add
to
it.
Does
that
help.
A
So
anyways,
what
I
would
usually
do
caps
look
is
great.
Oh,
I
didn't
start
the
thing
great.
Let
me
just
start
so.
Basically
what
what
I
have
the
way
I
describe
error,
handling
and
we'll
get
to
it
in
cubecon
and
stuff,
like
that,
I
didn't
show
off
error
handling.
I
would
just
have
the
entire
application
that
runs
the
workflow
and
the
three
services
run
in
the
same
application.
A
There
was
no
error
checking
so
if
things
fail,
basically,
if
the
serverless
workflow
language
says
that,
if
any
exception
during
workflow
execution
happens
a
runtime
exception
that
is
not
handled
by
the
workflow
workflow
execution
system
stop
so
in
case
my
three
services
were
not
available.
During
that
presentation
I
was
pretty
much
screwed
more
or
less
so.
What
I
would
usually
do
is
just
go
to
localhost
8080
type
in
a
new
patient
information
trigger
a
workflow
by
sending
a
cloud
event
to
my
mt
mqtp
broker.
A
That
would
trigger
an
instance
of
my
onboarding
event,
and
I
would
just
simply
call
these
three
services
sequentially
and
get
some
results,
but
in
real
life
applications,
as
we
all
know,
and
we're
trying
to
make
this
working
on
them
every
day.
This
is
a
demo
only,
especially
since
service
workflow
says
the
world
language,
that
targets
distributed
event
driven
and
distributed
or
orchestration
of
events
and
event-driven
distributed
services.
A
A
So
let's
say
right
now:
what's
happening
is
my
services
here
are
not
available,
so
let
you
know
they're
not
running
currently
so
once
my
workflow
here
tries
to
actually
invoke
the
store
new
patient
service,
it's
going
to
get
a
503
service
and
available
error
from
the
http
server
right.
And
how
do
we
deal
with
that?
So
we
have
an
on
errors
array
as
the
specification
defined
where
you
can
define
one
or
more
error
definitions.
A
Each
error
definition
has
an
error
parameter
and
this
can
be
used
to
be
mapped
to
certain
extent,
exceptions
by
the
runtime,
but
it
doesn't
have
to
be.
It
can
be
a
completely
logical
name,
and
we
also
have
a
code
parameter
which
can
help
run
times
to
map
the
specific
runtime
exception
that
it
receives
to
what
the
workflow
defines
and
the
runtime
that
I'm
using
here
does
exactly
that
in
case
the
rest
invocation
it's
going
to
hold
on
to
the
actual
http
response
code.
A
We
can
either
say:
okay,
if
we
or
define
or
catch
this
error,
we
can
say:
okay,
we
either
want
to
end
workflow
execution,
or
here
you
can
also
define
a
transition
of
course
where,
if
you
catch
this
particular
error,
you
can
transition
to
different
parts
of
your
workflow
to
know
how
to
handle
it.
For
this
demo,
I
simply
just
ended
the
workflow.
A
Now,
that's
all
okay
catching
errors.
It's
it's
a
must
in
any
workflow
language,
but
now
with
especially
distributed
systems,
we
want
to
recover
from
them.
What
does
that
mean?
Well
in
this
particular
case,
our
services
are
not
available,
so
we
added
a
retry
definition,
and
what
does
this
mean
we
want
to
when
we
catch
this
error?
We
want
to
issue
retries
and
we'll
look
at
how
we
do
that
here
in
a
second
and
what
does
it
mean?
A
We
want
to
periodically
retry
the
invocation
of
whichever
one
of
these
three
services
fails
and
once
if
we
are
actually
successful,
so
we
don't
get
this
error.
We
want
to
continue
so,
let's
say
the
store.
New
patient
information
services
is
up,
we
performed
it.
We
come
to
assigning
the
doctor
and
that
service
is
down.
At
that
point,
we
will
get
a
503.
A
We
would
retry
this
particular
service
as
per
our
retry
definition.
If
we're
not
successful,
we
will
just
follow
this
particular
transition
to
ending
the
workflow.
If
we
are
successful,
then
we
would
schedule
the
appointment
and
then
transition
to
the
states
and
definition
which
is
again
ending
the
workflow.
So
that's
that's
kind
of
like
what
I
wanted
to
show
in
the
demo.
If
we
look
at
our
retry
definition,
our
retry
definitions
are
reusable,
meaning
that
you
might
have
multiple
error
definitions.
A
A
There
is
many
parameters
and
we'll
improve
it
here
and
I'm
not
an
expert
on
retries.
That's
like
you're
again
and
the
other
guys
are
going
to
look
and
make
and
can
explain
anything
like
just
to
show.
There
is
like
multiplier
and
jitter,
and
I
think
more
that
we
are
having
issues
that
we
will
add
in
the
future.
A
But
simply
from
you
know,
we
have
a
delay,
which
is.
This
is
a
duration
format.
Pt3S
really
means
three
seconds,
so
we
here
define
that
we
want
three
seconds
in
between
retries
and
the
maximum
number
of
attempts
that
we
want
is
50.
In
this
case.
Let's
say
you
can
define
whatever
number
you
want
here
as
long
as
it's
greater
than
zero.
A
So
that's
pretty
much
it.
So
in
this
case,
what
we
have
is
we
catch
a
five
or
three
error,
we're
gonna
issue
retries
and
if
we're
successful,
we're
just
gonna
complete
workflow
execution
and
if
not
we're
just
gonna
go
ahead
and
end
it.
So
I
kind
of
played
around
with
this.
I
removed
the
some
of
the
system,
printouts
blah
blah
blah.
It
doesn't
matter,
but
you
know
I
don't
know
if
this
is
actually
going
to
work.
I
haven't
tested
this
in
a
couple
of
days,
but
I
hope
so
so.
A
I
usually
use
this
we're
going
to
start
a
workflow
instance.
The
services
are
down
right,
so
our
workflow
should
be
doing
our
retries.
Now
and
let's
say
he
has
chest
pain,
so
I'm
starting
a
new
workflow
instance
and
my
services
are
not
running
right
now,
so
our
workflows
are
every
three
seconds
trying
and
retrying
and
trying
the
retries
getting
a
503
issuing
a
new
retry.
A
A
D
A
But
if
for
this
runtime
we're
using
this
mapping,
it's
already
done
for
you
at
some
runtimes
they
might
have.
You
have
some
specific
mapping
that
you
have
to
define,
but
for
the
one
I
just
for
http,
like
you
said
you
know
you,
you
actually
gave
me
that
idea.
We
just
added
that
hey,
it's
http
response
code,
just
propagate
it
up
and
don't
force
the
user
to
map
those,
but
for
others
yeah
there
is
mapping.
D
B
D
It
happens
a
couple
of
times
that
your
micro
service
is
just
not
up
and
able
to
receive
the
call
I
mean
unless
you're
using
an
english
solution
like
native
or
yeah.
I
mean
this
is
really
cool
to
have
some
error,
handling,
demote
and
yeah.
Okay,
so
the
issue
on
the
jsonpatch
came
out.
We
cannot
discuss
this
week.
Is
ricardo
is
not
here,
but.
D
A
Sorry
yeah
please
go
ahead.
I
wanted
to
just
ask
like
I
know,
since
we
have
a
couple
new
people
here,
I
I
think
we're
always
interested
interest
to
know.
Okay
from
what
type
of
industry
you
guys
are
looking
for:
serverless
workflow
language
and
what
kind
of
situations
and,
if
you're
willing
to
share
it,
and
if
that's
okay,
it's
it's
really
cool
to
hear
those
things,
because
it
helps
us
out
kind
of
understand
the
community
in
general.
That's
around
the
specification.
B
Yens
and
it's
okay-
we
saw
this
two
weeks
ago
and
we
we
found
that
basically
by
accident
is
still
a
little
bit
hidden
in
the
cncf
and
at
the
moment,
we're
playing
around
yeah.
Just
to
give
you
the
state
where
we
are
we're
just
playing
around
and
we
just
let
this
back
and
we
are
trying.
That's
why
I
asked.
Where
can
we
ask
questions
slack
and
or
github?
Some
things
are
not
clear
to
us
at
this
stage,
but
we're
just
by
gathering
gathering
all
these
questions
and
and
yeah.
B
A
A
So
if
you
like
it,
of
course,
please
give
us
a
star
and
get
up
yeah,
that's
a
big
one
and
in
the
future
we
hope
that
we
have,
on
our
website
a
section
of
different
companies
that
and
how
just
a
generic
thing
like
how
they
use
the
specification.
That's
a
big
thing
for
us,
whether
you
actually
use
it
or
not.
If
you
have
something
good
to
say,
that
would
be
great
to
promote
it
for
the
specification
to
grow
the
community.
A
So
if
anybody
here
that
has
been
here
for
a
month
or
just
joined
feels
okay,
with
sharing
some,
whatever
information
about
how
they,
what
they're
thinking
about
it
or
how
they
might
consider
using
it,
please
share
that
with
us
and
and
if
that's
something
that
you
feel
comfortable
about
us,
maybe
using
is
a
somewhat
of
a
promotion
for
the
specification
to
help
us
out.
That
would
be
great.
E
Yeah
this
is
summer.
This
is
malik
again
here,
I'm
just
a
describe
about
our
situation
or
what
we're
trying
to
do
so
just
before
that,
I
want
to
quickly
understand
at
a
high
level.
Is
this:
you
were
doing
this
etheremer
with
your
own
interest,
or
you
have
been
asked
to
do
it.
How
does
it
work?
I
just
want
to
understand.
A
Definitely
so
to
kind
of
understand:
serverless
workflow.
It
is
a
cncf
project,
so
it
is
completely
vendor
neutral
and
it's
completely
platform
independent,
and
that
is
what
the
specification
actually
tries
to
do.
It
is
very
similar
to
a
cloud
events
we
actually
are
in
the
same
working
group
as
the
cloud
events
team
and
the
specification
came
from
the
serverless
work
working
group
at
cncf.
A
A
It's
completely
not
mandatory,
but
if
this
is
a
workflow
language,
it
specifies
so
it's
a
dsl
more
or
less
than
we're.
Creating
we're
also
creating
a
ecosystem
around
the
project,
such
as
language,
extensions
and
some
tooling
support.
Also
the
sdks
for
different
languages
in
order
and
the
main
thing
that
we're
trying
to
solve
is
to
have
a
vendor-neutral
workflow
language
in
the
domain
of
orchestration
of
events
and
event
driven
distributed
systems.
A
A
That
is
your
personal
interest
and
the
one
thing
that
that
is
important
about
this
project
that
I
think-
and
maybe
you
share
this
thought
with
me
or
not-
and
you
can,
of
course
everybody
has
their
own
opinion,
but
one
important
thing
is
that
not
only
is
this
a
vendor
neutral
and
based
on
cncf
or
is
a
cncf
project,
but
this
workflow
language
is
fully
community
driven.
So
anybody
any
one
of
you
or
your
companies
or
anybody.
My
generator
has
equal
rights
and
can
contribute
and
drive
our
vision
forward.
A
It
is
not
something
that
is
driven
by
some
companies
where
you
must
have
like
three
years
of
attending
meetings
to
even
have
a
say:
no
we're
a
small
community
and
we
welcome
everybody
and
really
that's
how
we
work
manuel.
Of
course,
we
have
cncf
code
of
conducts
and
rules
that
cncf,
of
course
provides.
But
those
are
our
limitations
as
far
as
that
goes.
A
A
A
I
think-
and
there
are
some
many
workflow
runtime
engines
out
there,
they're
dealing
with
many
different
kinds
of
workflow
languages,
serverless
vertical
languages
is
is,
can
be
either
adopted
by
the
existing
workflow
runtimes,
such
as,
for
example,
what
we
might
I
know
some
people
are,
or
even
what
I'm
working
at
a
redhead.
That's
what
kind
of
is
happening.
A
I
don't
know
for
others
specifically,
but
it
can
also
be
adopted
as
the
language
for
a
new
runtime
implementation,
but
no,
we
don't
intend
to
provide
the
there
might
be
a
default
runtime
implementation.
If
there
is
a
cncf
project
that
that
chooses
to
do
so,
but
we
will
not
promote
or
make
a
default
some
vendor.
You
know
specific
one.
We
will
always
promote
vendor.
How
do
you
say
runtimes?
E
A
E
D
D
I'm
aware
of
the
yeah
of
the
of
the
effort,
so
they
had
several
cube
controls.
It's
a
very
interesting
stateful,
serverless
project,
but
so
far
they
haven't
come
up.
I
I'm
not
monitoring
it
closely,
but
they
haven't
come
up
with
like
a
universal
workflow
language.
I
don't
know
how
much
they
are
implementing
anything
or
if
they
are
also
coming
up
with
their
own
workflow
language.
So
that's
a
little
bit
of
the
problem
that
we
see
is
that
there
are
purpose-built
platforms
like
tacton,
for
example,
for
ci
cd
argo.
D
But
there
is
no
independent
from
the
tooling
or
from
the
purpose
built
platform,
a
workflow
language
that
just
tries
to
capture
the
orchestration.
So
I
from
my
company
nokia
bell
labs
research.
So
that's
corporate
research,
it's
not
anything
product
backed
but
long
term.
I'd
be
hoping
to
have
this
as
an
orchestration
language.
In
the
cncf
that
is
implemented
by
more
than
one
engine
so
that
there
are
sufficient
providers
or
community
support
to
to
have
this
as
an
orchestration
language.
E
Okay,
I'm
trying
to
understand
how
this
this
will
fit
in
like
well.
If
we
choose,
I
know
that
we
are
planning
to
implement
something
again,
I'm
this
is
malik
from
american
express.
We
have
quite
a
bit
of
workflows
internally
right.
We
use
the
starting
from
small
workflow
products
to
even
a
bigger
workflow
engines.
We
use
kind
of
variety
of
things,
but
we
want
to
use
something
on
the
cloud
that
is
for
the
functions
to
build
something
similar
to
it.
E
We
wanted
to
figure
out,
you
know
what
options
we
have.
We
are
on
the
verge
of
kind
of
implementing.
Either
we
have
an
option
to
go
with
an
existing
workflow
engine
and
fit
our
functions
to
it
or
retrofit
our
functions
to
work
with
existing
engines,
or
we
can
go
with
a
newer
approach
using
not
to
name
any
like
we
are
still
trying
to
figure
out
what
would
be
the
best
implementation
engine
to
use
it
for
the
cloud
workflow
you
can
say
so
again
we
looked
at
cloud
state,
it's
still
still
in
primitive
state.
E
E
So,
but
that's
what
we
are
trying
to
as
much
as
possible
see
what
options
we
have
to
contribute
to
come
up
with
a
no
maybe
this
solution
that
that
you
get
trying
to
do
it
and
then
have
one
of
the
engine
implemented
and
how
how
to
put
this
all
together
and
how
long
it's
going
to
take.
It's
okay,
good
question.
I
don't
know
how
to
answer
it
answer
to
that.
A
C
A
Thanks
for
looking
at
us,
I
mean
here,
you
know
you
guys
can
look
at
what
we
have
ask.
Any
questions
contribute
as
much
as
you
feel
look
at
the
things
that
you
might
see
missing,
that
the
specification
might
not
be
implementing
and
it
will
definitely
put
those
on
the
radar
as
well.
So
yeah
I
mean
thank
you
and
and
yeah.
If
you,
if
you
want
some
comparisons,
we
do
have
some
comparisons
to
the
or
examples
comparisons
to
brigade
and
argo.
But
it
would
be
nice
to
also
have
kind
of
comparison.
A
Examples
like
what
we
already
started
with
with
maybe
some
other
workflow
languages
that
will
help
the
community
kind
of
take
a
look
at
those
and
and
and
be
able
to
quickly
see
the
differences,
the
commonalities
and
things
like
that
and
make
a
good
decision
about
where
they
want
to
go.
Moving
forward.