►
From YouTube: CNCF Serverless Working Group 2021-01-14
Description
CNCF Serverless Working Group 2021-01-14
A
Just
so
you
know:
well,
it
doesn't
really
matter
for
much.
We
do
kind
of
keep
track
of
people's
attendance
and
that's
how
you
kind
of
get
voting
rights
if
you're
here
for
like
the
three
to
three
out
of
the
last
four
meetings,
I'm
like
that
and
voting
rights
are
based
upon
companies.
So,
if
you'd
like
to
be
associated
with
a
company,
just
let
me
know
the
company
name
and
I'll.
Add
you
to
the
to
the
tracker
to
that
company.
C
A
D
D
B
G
F
G
A
G
G
E
A
A
J
A
A
A
A
A
All
right,
in
that
case,
kubecon
eu,
may
4th
through
the
7th
we
get
a
35
minute
speaker
session
or
maintainer's
track
session.
So
as
usual,
we're
looking
for
volunteers,
if
you
are
interested
in
speaking,
please
reach
out
to
me,
you
don't
have
to
be
an
old-timer.
You
can
be
new
to
the
group
anybody's
welcome
to
do
it.
This
is
just
you
know,
provide
an
overview
of
what
the
specs
are
about
or
our
status,
nothing
too
deep,
but
it
is
a
good
opportunity
to
get
face
time
for
the
community.
A
F
A
But
actually
that
on
that
note
you
know
if
you
are
interested
in
doing
it,
we
have
lots
of
powerpoint
slide
decks
from
previous
talks.
So
a
lot
of
it
is
just
repeating
the
same
thing
we've
already
said,
but
you
know
some
people's
companies
actually
really
care
about
those
kind
of
things
from
tracking
and
performance
perspectives.
Hey
here's
your
opportunity
to
get
out
there
so
just
reach
out
to
me.
I
think
ginger
you
tend
to
know
this
stuff.
Do
you
remember
what
the
deadline
is
for
saying
yes
or
no
to
this
stuff?
A
A
Want
to
you
want
to
accept
a
separate
email
either.
You
can
do
it
to
me
in
the
chat.
If
you
want.
Thank
you
all
right,
sdk,
I
don't
see.
Oh
there
he
is
tumor.
He
there,
I'm
sorry.
I
gotta
hit
myself.
It's
not
sdk,
I'm
sorry,
okay,
so
we
have
an
sdk
call
this
week,
but
last
time
I
checked,
we
have
nothing
on
the
agenda.
So
if
you
are
interested
in
a
topic,
please
add
it.
A
Discovery
call
will
be
next
week.
However,
I
would
like
to
have
a
brief
discussion,
so
if
the
sdk
call
has
no
agenda
items,
I
would
like
to
have
a
discovery
interrupt
call
immediately
following
this
one.
So
please
stick
around
if
you're
interested
in
either
one
of
those
topics.
Okay,
now
tmr
back
to
you
anything,
you
want
to
mention
relative
to
workflow.
B
B
We
have
also
added
reusability
of
expressions,
so
they
can
be
referenced
by
name
throughout
the
workflow
and
we're
looking
at
bigger
things
like
dynamic
condition,
evaluation
and
things
like
that.
So
there's
a
lot
of
movement
going
on
starting
this
year.
So
I'm
happy
about
that
and
and
yeah
the
community
seems
to
be
growing
a
little
thanks,
cool.
K
A
A
C
A
K
I
K
A
Okay,
would
it
make
sense,
then,
for
you
to
look
at
the
community
bridge
stuff
to
see
if
that
would
satisfy
your
needs?
Because
if,
if
google
summer
code
has
some
potential
legalistic
issues
or
just
issues
in
general,
that
that
bother
at
least
some
of
the
members
of
our
community,
but
community
bridge
doesn't,
but
they
get
the
same
net
results.
Maybe
we
should
look
at
community
bridge.
L
G
K
Well,
I
I
I
write
down
at
the
end
of
the
comment.
If
you
don't
worry,
if
you
don't
want
to
remove
this,
I'm
fine
but
yeah,
just
just
let's
make
sure
people
understand
this
because
so
much
times
I
I
got
these
questions
bought
in
slack
in
other
communities
in
these
in
the
sdk.
So
I
mean
at
least,
let's
give
it
a
name
that
makes
clear
what's
the
goal
of
that
extension,
but
it's
literally
that.
G
G
You
have
an
application,
a
which
is
issuing
an
event,
and
it
has
a
it
has
a
context,
and
then
there
is
some
black
box
infrastructure
of
of
arbitrary
complexity
which
goes
and
pops
out
an
event
to
a
receiver,
and
they
then
go
and
keep
going
with
that
tracing
information
at
their
level
and-
and
neither
party
cares
about
the
internals
of
that
of
that
infrastructure.
That's
carrying
that
event.
G
M
K
K
G
K
M
K
M
K
Well
but
but
I
I
stop
you
right
now,
because
we
talked
about
that
months
ago,
that
we
shouldn't
overlap
with
what
other
standard
standard
organizations
are
doing
for
developing
tracing
tools
on
each
protocol.
So
we
we
don't
want
to
create
an
obstruction
on
that
that
we
talked
a
lot
of
times
about
that.
So
right.
M
K
G
Same
concept,
if
you,
if
you,
if
you
roll
your
suitcase
in
a
in
a
drive
in
a
moving
train,
yes,
you
move
forward
and
both
of
you
move
forward,
but
the
moving
is
completely
independent
of
each
other.
So
it's
the
same
concept.
We
are
here.
We
are
moving.
We
there's
a
there's,
there's
there's
an
underlying
transport
infrastructure,
which
we
don't
understand
how
that
works,
and
we
can't
we.
G
We
don't
influence
it,
but
we
want
to
make
sure
that
the
functionality
that
is
that
is
realized
on
top
of
it
works
independent
of
it,
but
that
is
relying
itself
on
the
same
kind
of
tracing
infrastructure,
so
the
concepts
and
the
frameworks-
and
everything
is
the
same,
so
I
mean,
if
you
rename
those
things.
How
do
you
then
say?
Oh
this
ties
into
tracing,
because
ultimately
we
want
this
to
end
up
in
the
same
in
the
same
kind
of
infrastructure.
We
want
this
to
be
integrated
in
the
same
infrastructure.
G
A
So
so,
if
the
biggest
concern
here
is
around
possible
confusion,
well
no
wait,
never
mind.
I
was
going
to
say
so:
slinky
are
there?
Are
there
particular
areas
that
you
think
are
more
confusing
or
that
that
are
really
that
are
really
tripping
people
up,
and
maybe
we
can
just
focus
on
those
particular
things
and
see
if
we
can
address
those
instead
of
instead
of
just
saying
we're
going
to
try
to
kill
the
entire
spec.
K
G
But
then
you
have
an
event
that
has
been
published
by
someone
right
and
you
have
the
event
that
has
been
received
by
someone
else
and
there's
a
relationship
between
those
two
which
is
not
represented
by
either
the
the
request
that
that
start
the
event,
nor
the
requests
that
retrieve
the
event
they
have
a
completely
different
relationship
with
each
other,
and
that
is
the
customer,
has
a
new
shipping
address
right.
That
is
the
event,
and
that
was
caused
by
some
business
activity.
G
And
now
I
continue
that
business
activity
with
I'm
gonna
send
that
that
customer
a
piece
of
mail-
that's
the
stuff
that
happens
at
that
level
of
of
the
app
on
the
application
level
and
that
activity,
which
is
you
know,
cause
and
effect
that
requires
tracing.
That
has
nothing
to
do
with
those
two
http
requests
nothing.
So,
yes,
it
is
exactly
the
same
mechanism,
but
at
a
lo
different
level
of
a
level
of
abstraction.
A
G
K
G
K
G
But
it's
just
an
end
to
end
it's
just
you
just
look
at
it
from
the
app
perspective
you
just
go
in
and
and
and
and
tune
out,
all
the
plumbing.
That's
underneath
it
and
you
only
look
at
the
app
I
mean
we're
ultimately
we're.
Let
me
take
one
step
further
back
right.
We
are
the
serverless
working
group.
K
K
A
K
I
A
A
Just
in
case,
you
run
out
of
time
these
next,
these
three
pr's,
I
believe,
are
technically
waiting
on
updates
from
people.
So
I
think
this
is
lance.
I
think
this
is
clemens.
I
think
I
can
remember
who
this
one
is,
but
if
you,
if
you
want
any
of
these
three,
please
work
on
those
updates,
because
I
think
they're
at
least
outstanding
comments,
if
not,
if
not
just
action
items
to
do
something.
Yeah.
A
Okay,
cool!
Thank
you.
Okay.
What
I
wanted
to
do
was
talk
about
this
pr.
I
now
this
one
actually
only
I
think
I
already
have
here
this
pr
was
opened
up
as
a
result
of
this
issue,
where
there
was
some
confusion
between
config
and
protocol
settings,
and
I
opened
up
this
pr
to
try
to
address
that
and
I'm
not
going
to
try
to
do
a
vote
or
anything
on
here,
because
I
want
people
to
take
time
to
read
it.
A
A
A
What
I
did
is,
I
said
there
are
basically
three
conceptual
phases
and
I
purposely
use
the
word
conceptual
because
how
you
choose
implement
this
is
is
up
to
you,
but
I
thought
there
was
three
phases.
One
was
the
event
generation
phase.
Okay.
Then
there
was
the
event
filtering
phase,
and
then
there
was
transmitting
the
event
to
the
sync.
As
I
said,
obviously,
you
could
choose
to
do
all
three
in
one
you
could
choose.
You
know,
however,
you
want
to
code.
A
This
up
is
up
to
you,
but
I
think,
as
you're
coming
up
with
these
various
options
between
config
filters
and
protocol
settings,
I
think
most
people.
I
think
anyway,
have
these
three
phases
sort
of
in
mind
and
that's
why
we
have
three
different
configuration
settings.
Okay,
and
so
what
I
try
to
do
is
talk
about
those
three
phases
and
says,
oh
and
by
the
way,
if
you
want
to
modify
something
that
goes
on
in
this
phase,
here's
the
property
to
use
to
modify
that
particular
phase.
A
A
I'm
sorry
when
someone
reads
the
service
description,
it
needs
to
be
very
clear
which
particular
flag
influences
which
part
of
the
event
processing.
So,
for
example,
if
I
define
a
configuration
option
that
influences
say
filtering
and
event
transmission,
the
definition
of
that
configuration
option
needs
to
explicitly
state
that
to
someone,
so
they
know
which
flag
to
use
when,
regardless
of
which
particular
bucket
these
things
go
into
because
I'll
be
honest
with
you,
as
I
was
thinking
about
this
issue
over
the
christmas
break,
part
of
me
jumped
to
well.
A
Is
this
really
that
different
from
our
extensions
thing?
Where
everybody
kept
saying
well,
we
need
to
have
buckets
for
extensions
right
and
possibly
different
buckets
for
different
things
and,
at
one
point
my
mind
jumped
to
well.
Let's
get
rid
of
all
these
three
things
right
and
just
have
the
idea
of
just
add
your
random
quote
extension
to
define
your
own
flag
and
you
tell
us
what
that
means,
but
then
I
realized
that
we
need
some
consistency
so
think
of
those
over
example.
We
don't
want
everybody
to
find
their
own
filtering
thing
right.
A
So
that's
that
that's
why
I
ended
up
saying:
okay,
we
can't
kill
off
the
idea
of
the
buckets,
but
we
do
need
to
be
very
clear
in
terms
of
how
they're
going
to
be
used
as
people
use
them
or
to
define
them
in
their
server
subscription
or
I'm
sorry,
yeah,
service,
service,
description,
okay,
so
take
take
the
time
read
this
see
if
it's
on
the
right
path,
I'll
take
any
wording
changes.
People
want
to
make
even
the
idea
of
killing
three
conceptual
phases.
Maybe
that's
wrong.
A
A
A
Okay,
cool.
Thank
you.
Please
take
your
time
to
read
that
now
and
keep
in
mind.
It
is.
This
is
a
change
for
the
subscription
api
spec,
but
I
actually
think
this
may
be
better
suited
for
a
primer.
If
we
ever
do
create
one,
I
think
it's,
I
think
it's
not
quite
speccy
enough,
but
that's
a
different,
separate
discussion.
A
Okay,
so,
first
of
all,
the
scenario
here
is
a
user
wants
to
subscribe
to
the
cr.
The
issue
created
event,
as
well
as
the
repo
push
event.
Okay.
Now
I
phrased
these
in
terms
of
the
types
that
we
defined
in
our
github
adapter.
Obviously,
these
are
not
the
strings
that
github
itself
knows
about
and
we'll
talk
about
that
in
a
minute,
but
this
is
the
general
scenario
that
I
sort
of
walk
through.
Okay.
Now,
if
I
was
to
create
a
github
subscription
manager
today,
what
I
would
probably
do
is
make
it
so.
A
A
You
can
specify
the
sync
and
then
you
specify
some
options,
in
particular
the
owner,
the
repo
and
then
the
events
that
you
want.
Okay,
now
I
tried
to
write
this
up
with
as
few
changes
to
github
processing
as
possible,
meaning
I
just
wanted
to
write
a
very
thin
sort
of
veneer
on
top
of
what
github
does
today,
which
is
why
I
did
not
use
filters
because
they
don't
have
the
idea
of
filters.
At
least
they
don't
talk
about
them
as
filters
right.
They
talk
about
just
oh.
A
What
events
do
you
want
to
see
and
I'll
talk
about
later
about
how
we
actually
could
use
filters
to
do
that,
but
keeping
this
to
the
minimal?
I
decided
skip
filters
and
just
put
this
all
in
config,
okay
and
it
and
github
expresses
these
things
as
three
separate
entities
owner
repo
and
then
list
of
events.
So
this
is
would
be
my
first
pass
as
trying
to
write
a
subscription
manager
for
github,
okay
and
now
this
presented
some
interesting
aspects.
First
filters
don't
mean
anything
in
my
opinion
to
get
up.
Okay.
A
Now
it
is
possible
that
they
implemented
the
idea
of
which
events
you
want
to
see
as
filters,
but
I
decided
to
say
nope
they
didn't
and
they
chose
to
do
it
the
exact
same
way
as
they're
doing
owner
and
repo
and
have
a
little
more
of
a
hard-coded
nature
to
it,
because
I
think
it's
perfectly
allowable
for
someone
to
actually
code
up
their
subscription
manager
that
way.
Okay.
So
my
the
first
thing
I
came
to
in
this
was
filters
needs
to
be
optional,
for
a
subscription
manager
to
support.
G
G
That
is
the
thing
you're
interested
in
you're
interested
in
events
about
that
repo
and
then
that
repo
starts
giving
you
events
of
of
all
the
kinds
of
things
that
may
happen
in
that
center.
Repo,
a
new
issue
is
being
created,
a
new
pull
request
is
being
created,
etc
and
then
with
the
filter,
you
can
then
go
and
further
constrain.
G
A
Well,
maybe,
but
but
but
you
get
my
point
right
right
because
do
we
want
to
force
someone
to
say
no,
you
have
to
have
a
subscription
manager
per
source,
or
can
you
have
a
generic
endpoint
that
handles
everything?
And
then
at
that
point,
do
you
make
does
source
have
to
be
quote
a
filter
or
it
could
be
a
config
option
right
and
my
mind
immediately
jumped
to
well.
We
want
the
spec
to
be
as
widely
adopted
as
possible.
G
I
I
I
I
think,
there's
a
there's
a
the
the
question
here
is:
what
is
the
subscription
manager
scope
to,
because
my
belief
is
that
the
subscription
manager
is
managing
subscriptions
for
a
source?
So
there
is
not
one
subscription
manager
per
system,
but
there
are
a
system
might
have
tens
of
thousands
of
them
conceptually
right.
Virtually.
You
may
have
one
implementation,
but
really
you
can
you
can
subscribe.
You
can
walk
up
to
an
object.
You
can
walk
up
to
a
resource
in
in
on
a
site
and
can
ask
the
resource
to
subscribe.
G
So
I'm
really
thinking
of
that,
if
you,
if
you
think
about
this
in
http
terms,
I'm
really
thinking
about
this
in
a
very
extremely
rustifarian
way
in
where
literally
a
a
you
have
a
discovery
overlay
over
your
resource
graph,
which
tells
you
in
this
graph
there
is
decent
decent.
These
objects
can
raise
these
in
these
events
and
then
you
just
walk
up
to
those
objects
and
say
I
want
to
go
and
subscribe.
A
Yep
I
get
that
I
I
completely
understand
that
model,
I'm
just
my
mind,
just
isn't
there
yet
that
says
that
has
to
be
the
model
as
opposed
to
a
single
subscription
manager
that
supports
multiple
sources.
That's
that's
where
I'm
struggling
with
all
this,
but
let's
go
to
the
queue
since
people
have
their
hands
up.
Klaus,
I
think
you
were
first
yeah.
N
So
just
some
thought
that
came
to
my
mind
when
looking
at
this,
it's
quite
interesting.
It
reminded
me
a
bit
of
we
added
this.
I
think
it's
called
source
template
or
pattern
to
the
discovery
spec,
and
then
we
had
those
parameter
values
that
could
be
added,
and
I
think
for
this
example.
They
would
exactly
correspond
to
those
config
values
you
have
here,
so
you
would
have
then
a
source
pattern
like
github.com
and
then
slash
owner
and
curly
braces
and
slash
repo
and
curly
braces.
N
A
G
One
either
or-
and
I
don't-
and
I
don't
think
we-
I
think
both
I
think
both
are
possible.
There
is
this,
so
what
I
just
explained
was
the
the
I
already
said
that
that's
a
very
rastafarian
view
is
everything
can
have
a
resource
it
can
have
a
subscription
manager.
Of
course,
you
can
also
have
the
simpler
view
of
having
a
single
endpoint
for
subscription
management,
but
then
you
would
then
you
need
to
go
and
pass
the
source
as
a
parameter.
What's
what's
what's
a
little?
G
N
G
A
G
But
then
you're
subscribing
to
the
read
with
github.
It's
actually
a
very
simple
example,
because
it's
a
strict
hierarchy,
you
could
subscribe
to
github
and
then
get
everything,
that's
related
to
everything
in
github
and
just
filter
it
down
or
you
can
go
and
subscribe
to
a
repo.
And
then
you
get
everything,
that's
related
to
the
repo
and
filter
only
that
down
or
you
could
go
and
subscribe
to
everything.
That's
ins
that
happens
to
a
particular
file
and
then
and
then
you
might
go
and
filter
just
some
subset
of
of
those
those
events
down.
Oh.
I
J
So
filters
I
thought
filters
was
always
a
section
where
we
specify
a
cloud
event
attribute
in
in
manner
to
receive
the
events
or
to
filter
the
events
for
the
consumer
right.
So
if
you
want
to
filter
what
a
subscriber
needs,
it's
usually
based
on
a
cloud
event
attribute
right
and
coming
to
the
questions
of
github
like
for
example,
now
github
is
just
not
github.com.
There
are
thousands
of
enterprise
githubs.
J
So
if
we
don't
mention
a
filter
criteria
based
on
source,
I
I
see
that
as
a
problem,
because
filter
was
always
like.
I
don't
know
whether
that's
still
in
the
case
of,
for
example,
k
native
k
native
introduces
source
as
a
filter
type
as
a
filter
criteria.
So
are
we
completely
going
to
ignore
that
now.
A
So
my
perspective
was,
I
think,
source
should
be
a
valid
thing.
You
can
filter
on
okay,
so
I
do.
I
do
agree
with
you
on
that.
On
that
point,
however,
as
I
was
walking
through
this,
I
realized
that
there
may
be
things
that
people
need
to
filter
on
that.
Don't
necessarily
show
up
in
the
message
and
therefore
I'm
thinking
we
need
to
support
the
idea
of
filtering
on
those
non-cloud
event,
attributes
or
non-event
attributes.
A
J
Okay,
and
also
the
conflict
thing
is,
is
also
a
bit
confusing,
because
conflict
can
not
only
be
in
in
terms
of
the
event
delivery.
It
can
also
be,
let's
say,
introducing
properties
in
order
to
re
in
order
to
communicate
with
the
sink.
So
what
if
the
sink
was
protected
by
some
sort
of
client
credentials-
and
you
want
to
also
so
config-
becomes
this
huge
generic
envelope,
where
you
want
to
just
stuff
everything
or
what
so,
I'm.
A
A
Well,
that's
that's
kind
of
why
down
here.
I
talked
about
how
on
the
previous
pr,
how
any
one
of
these
could
influence
many
different
things
or
or
everything
right,
but
and
and
that's
when
I
was
starting
to
struggle
because
as
if
I'm
implementing
this
thing,
I
don't
necessarily
want
this
specification
to
force
me
to
change
my
implementation
right
so
anyway,
okay
amid
you're
next.
E
Yes,
so
I
want
to
go
back
to
the
allowed
values
for
source
and
where
I
want
to
put
it.
One
question
I
have
is
that:
are
we,
for
example,
supporting
expressions
for
source
as
well,
and
this
is
something
we
were
discussing
earlier?
What
if
the
subscriber
is
interested
in
receiving?
You
know
some
patterns
of
source
when
subscribing
say,
for
example,
I
don't
know
all
the
files
in
a
github
repo
that
have
this
specific
extension
name.
E
A
G
G
So
let's
say
under
github.com
slash
cloud
event:
spec
there
is
a
slash
dollar
subscription,
endpoint
that
you
can
talk
that
you
can
talk
to
and
then
you
would
want
to
walk
up
to
that
and
you
would
scroll
subscribe
and
now
you're
going
to
specify
a
filter
and
the
filter
is
a
prefix
filter
on
subject,
slash
main
slash
tree.
No,
sorry,
slash
three
slash
main.
G
I
don't
know,
I
don't
exactly
forget,
slash
whatever
file,
and
so
you
specify
a
specify,
a
file
path
and
then
events
are
getting
raised,
but
only
the
ones
that
are
that
are
related
to
a
particular
file.
Prefix
would
then
be,
would
then
be
given
to
you
and
that
filter
would
be
on
the
subject.
Property.
E
G
Is
that
what
you're,
seeing
the
the
the
split
we
have
in
the
structure
is
in
the
metadata
structure?
Is
we
have
source
and
subject
and
think
of
that
as
source
is
the
scoping
for
where
you
subscribe
and
then
subject
is
the
path
to
the
object
about
about
which
the
the
path
to
the
object
within
that
scope
to
which
the
event
actually
applies?
G
You're
subscribing
on
a
con
on
a
storage
container
right
containers
are
our
directories
where
you
can
go
and
store
blobs.
That's
why
that's
where
you
subscribe?
That's
yours,
that's
your
scope
and
effectively.
That's
also
the
subscription
manager
you
talk
to
and
then
that
thing
is
raising
events
where
it
gives
this
the
the
container
as
its
its
scope
as
its
source.
G
G
But
the
scope
is
always
the
container
and
then
you
with
a
subject
which
composes
with
that
container
name.
You
then
get
to
select
which
of
the
events
scope
to
which
sub-object
inside
of
that
container
you're.
Getting
events
for
and
that's
that's
a
model,
that's
working
for
a
ton
of
different
scenarios
from
you
know.
A
E
A
E
O
A
O
G
P
I
think
your
hands
up
yeah,
I
think
I'm
pretty
aligned
with
what
scott
said.
Like
my
goal
as
a
manager,
the
full
id
of
the
company
is
basically
to
have
those
kind
of
tier,
like
middle
tier,
where
I
connect
all
the
external
service
to
mine,
and
then
I
will
give
access
to
a
subscription
api
to
my
internal,
like
my
employees
and
with
some
restrictions
permission
that
is
managed
directly
on
that
subscription
api,
and
I
think
that's
the
difficulty
that
you
were
raising
doug.
P
A
A
P
Thinking
because,
like
let's
say
guitar,
so
I
manage
github,
I'm
like
the
top
of
the
enterprise
of
github,
so
I'll
get
all
the
events
from
all
our
repo.
But
then
I
want
to
dispatch
it
and
filter
it
for
each
team
inside
the
company.
So
we
are
not
like.
We
are
a
small
company
like
we
are
200
people
so
compared
to
the
size
of
the
other
gentlemen,
it's
really
small,
but
when
you
do
that,
that
means
I
have
keys
to
get
all
the
events
from
github.
P
P
Internally,
I
can
push
for
like
a
certificate
authentication,
while
I'm
connected
to
github
using
their
token
systems.
Usually
so
I
can
have
a
break
of
authentication
and
security
between
my
middleware,
where
it's
connect
to
and
what
you
provide
to
my
internal
customers.
So
that's
that
was
my
goal.
I
think
I
tried
to
explain
in
the
past
probably
badly.
I
still
have
to
write
a
better
document
about
that,
but
that's
my
overall
thinking
and
why
I
joined
this
group.
L
A
Right
but
see-
and
I
got
almost
out
of
time-
this
is
a
great
conversation,
though
you
know
conceptually
scott.
I
would
agree
with
you,
but
the
problem
that
I
run
into
is:
okay,
fine,
if
that's
true
when
you,
if
we
actually
do
support
something
like
an
sql
query
thing
right.
I
can
imagine
that
this
query
also
including
a
subject
right
as
part
of
the
and
condition
or
part
of
the
part
of
the
condition
right
and
what
you
just
said
is
like
okay.
A
That
means
someone
needs
to
analyze
this
sql
query
and
remove
the
subject
or
remove
the
equivalent
of
the
event
producer
from
this
condition
before
he
passes
it
up
the
chain
and
removing
that
from
this
sql
query
can
be
very
complicated
without
without
ensuring
that
you
don't
lose
the
desired
semantics,
and
that's
when
I
start
thinking.
Oh,
my
gosh
we're
over
complicating
this
thing.
O
A
Sql
get
added
well.
This
was
all
part
of
the
previous
discussions
anyway,
we're
technically
out
of
time.
Obviously,
as
I
said,
this
conversation's
going
to
keep
going,
but
this
this
doc
is
linked
in
in
this
issue,
7724
down
here
with
some
of
my
thoughts
of
things
I
wanted
to
discuss
with
people
before
I
went
through
the
pain
of
opening
up
a
pr
that
may
not
be
valid,
but
I
do
want
to
continue
the
discussion
in
future
calls.
A
So
please,
when
you
get
a
chance
to
look
at
this
doc,
add
comments
to
it
and
stuff
like
that,
because
I
think
the
answering
some
of
these
questions,
as
I
was
walking
through
this,
I
think,
is
going
to
help
us
clarify
the
way
the
specs
should
be
written,
because
I
think
there
are
a
lot
of
things
we
haven't
even
thought
about.
Yet,
okay,
all
right
technical
time,
I
apologize
brian.
Are
you
there.
A
A
Okay,
in
that
case,
thank
you
all
for
joining.
If
you
are
interested
in
the
sdk
or
the
discovery
interrupt
please
take
on
the
call,
I
know
scott,
you
have
to
leave,
so
I'm
probably
able
to
make
it,
but
I
did
want
to
talk
very
briefly
about
the
interop
stuff,
just
for
five
seconds
or
so.
Okay.
So
thank
you.
Everybody
for
joining
we'll
talk
again
next
week.
A
A
A
M
A
C
C
So
at
our
organization,
we're
currently
utilizing
laravel,
which
is
a
common
php
framework
on
top
of
lambda
and
some
other
aws
services,
and
we
see
that
you
know
there's
there's
a
need
within
our
organization
for
allowing
us
to
use
a
php
sdk
for
cloud
events
and
then
to
also
be
able
to
use
that
alongside
some
some
other
languages
and
services
that
we
have.
So
I
I
know
that,
like
I
said,
the
new
guy
raised
this
topic,
but
also
I'd
like
to
figure
out
how
I
can
support
that.
C
I
don't
know
if
there's
an
active,
maintainer
or
a
point
of
contact
there,
but
I
have
set
up
a
a
fork
myself
and
read
through
some
of
the
governance
there.
I
just
want
to
make
sure
that
if
we
do
get
this
rolling
that
I
can
help
set
a
good
foundation
for
this,
because
I
think
that
you
know
the
php
community
would
really
benefit
from
cloud
events.
C
A
Okay,
well
cool.
Well
again,
thank
you
for
joining
as
you
as
you
know,
there
really
isn't
much
there
today,
so
this
is
wide
open
and
anything
you
want
to
throw
at
it
we're
all
for
in
the
past,
when
someone
new
came
along
and
said,
hey,
you
guys,
don't
have
it
for
this
language.
I
want
to
do
it.
They
would
immediately
become
a
maintainer,
because
no
one
else
is
doing
it,
so
it
made
perfect
sense.
A
I
need
to
go
back
and
double
check,
because
we
just
recently
introduced
a
whole
bunch
of
governance
rules
about
how
maintainers
are
created,
and
I
need
to
go
back
and
refresh
my
memory
about
how
we
do
maintainers
for
brand
new
languages
now
printed.
This
isn't
technically
new
repo,
but
for
all
intents
and
purposes
it
is
new
right,
but
chances
are
you
will
be
able
to
make
you
a
maintainer
and
then
feel
free
to
do
pretty
much
whatever
you
want.
A
As
long
as
it's
headed
in
the
right
direction,
I
would
look
at
the
other
sdks
to
get
guidance
in
terms
of
how
they
operate
or
what
they've
done
in
terms
of
design
choices.
We
do
have
an
sdk
readme
or
a
md
file
at
the
root
of
our
repo,
that
people
would
add
to
occasionally
to
provide
guidance
for
other
sdk
authors.
If
you
want
to
look
at
that,
but
otherwise
to
be
honest,
it's
kind
of
a
free-for-all
for
you
right
now.
C
Okay
sounds
good,
I
know
there's
a
lot
of
really
great
examples.
I
use
go
in
my
day-to-day
and
I'm
a
big.
You
know
I'm
a
gopher,
so
I
plan
to
use
that
sdk
as
a
good
example.
Just
because
I
really
like
the
api
there
as
well
as
I
know
that
there
are
those
conformance
tests
that
are
available.
I
don't
know
if
those
are
part
of
the
spec
repo
or
somewhere,
but
I've
got
that
bookmarked.
C
So
I
like
to
go
ahead
and
just
use
kind
of
the
go,
and
maybe
even
the
rest.
Sdk
is
good
examples
and
just
try
and
maintain
the
the
good
work.
That's
already
been
done
in
those
sdks
as
part
of
the
php
stuff,
just
to
bring
it
along.
So
so
long
as
it's
a
good
plan
I'll
start
making
some
progress
there
and
pinging
people
yeah.
A
A
Okay,
the
only
thing
that
popped
in
my
head,
as
we
were
talking
about
this
is
sometimes
people
have
often
when
they
look
at
situations
like
this.
They
try
to
say.
Oh,
we
should
have
tried
to
have
commonality
across
the
sdks
and
their
definition
of
commonality
will
vary
right.
Some
people
say
we
want
to
make
sure
we
support
similar
features,
while
other
people
actually
go
as
far
as
to
say.
A
Well,
let's
make
the
user
experience
similar
and
that
could
get
kind
of
tricky
right,
because
I
think
where
we've
landed,
please
other
sdk
guys
speak
up
because
I'm
not
technically
an
sk
person,
but
I
think
where
we've
landed
is
first
and
foremost
the
user
of
an
sdk
wants
the
sd.
We
want
the
sdk
to
feel
like
a
natural
extension
of
that
particular
language
right
so,
for
example,
it'd
be
a
mistake
to
introduce
golang
isms
into
a
php
sdk
unless
a
php
user
would
be
feel
perfectly
natural
with
that
particular
mechanism
right.
A
A
C
Yeah
for
sure,
so
we
have
a
few
internal
devs
who
are
pretty
much
full-time
php.
So
I'll
also
kind
of
kick
the
tires
around
internally
since
we're
wanting
to
use
this
in
our
as
a
daily
driver,
so
I'll
get
feedback
from
some
people
internal
and
of
course,
you
know,
look
for
any
feedback
from
the
community
on
making
sure
that
it's
php
centric.
A
A
All
right,
in
that
case,
let's
switch
over
to
the
interrupt
thing
for
a
sec.
There
were
basically
a
couple
of
objectives
that
I
wanted
to
early
that
I
have
and
in
terms
of
having
this
call
today,
even
though
it's
not
scheduled
for
next
week.
First
is
we
originally
talked
about
having
interop
event
in
november.
Obviously
that
did
not
happen,
and
I
know
everybody
was
busy
and
I'm
not
I'm
not
pointing
fingers,
because
I
know
everybody
myself
included
just
got
swamped
and
just
didn't
happen
for
a
variety
of
reasons.
A
However,
I
do
think
we
need
to
push
ourselves
and
nag
ourselves
to
make
something
happen
here.
Now
I
think,
going
through
this
type
of
exercise
is
going
to
be
a
great
in
terms
of
trying
to
flesh
out
the
spec.
I
think
that's
all
well
and
good,
and
I
at
the
same
time,
though,
I
do
think
having
some
sort
of
interop,
even
though
I
do
think
it
may
be
a
little
premature,
given
some
of
the
huge
design
discussions
that
we're
having
today.
A
I
do
think
it
would
be
useful
to
have
at
least
the
start
of
people
coding
to
help
expose
even
more
design
gaps.
Okay,
and
so
what
I
did
was
over
the
last
couple
of
days
is.
I
wrote
down
very
quickly
what
I
would
expect:
a
implementation
of
a
discovery,
endpoint,
a
implementation
of
a
subscription
manager
to
look
like
or
to
support
from
a
testing
perspective.
Okay.
So,
for
example,
if,
if
you're
going
to
participate
in
the
interrupt
your
discovery,
endpoint
needs
to
do
this
right,
it
has
to
be
able
to
support.
A
You
know
up
to
at
least
100
different
services
in
there,
so
we
can
get
pagination
testing
going
right,
but
not
necessarily
all
the
time
maybe
have
a
flag.
That
tells
you
how
many
you
want
right.
These
are
all
various
things
I
thought
people
should
be
forced
to
try
to
implement
as
part
of
their
interop
coding
efforts
and
then
the
the
tester
or
the
client
who
or
the
person
who
writes
up
the
client
they
need
to
test
various
things.
A
So
I
started
just
quickly
jotting
down
what
I
thought
they
should
test,
and
then
I
did
the
same
thing
for
subscription
manager
right.
So,
for
example,
I
think
we
need
to
have
common
services
so
that
clients
don't
have
to
change
their
code
when
they
subscribe
for
every
single
endpoint.
Rather
we
have
common
subscriptions
or
common
services
available
right,
so
people
can
get
similar
semantics.
A
So
these
are
kind
of
things
that
I
thought
we
need
to
sort
of
agree
upon
as
part
of
an
interop
thing,
and
what
I
wanted
to
do
was
to
mention
this
today,
so
you
guys
could
take
a
look
at
it
and
start
iterating
on
this
list.
That
way,
people
have
a
little
bit
more
concreteness
to
what
they're
supposed
to
be
coding,
because
I
think
one
of
the
reasons
it
was
hard
for
us
to
make
forward
progress
here
was
it
was
a
little
bit
nebulous
in
terms
of
what
people
were
coding
up
right.
A
All
we
basically
said
is
here:
here's
the
spec
go
code.
It
and
you
can
do
that
to
some
extent,
but
I
think
it's
easier
when
you
have
something
very
concrete
in
mind
and
that's
what
I
was
trying
to
do
was
give
very
concrete
scenarios
that
we
expect
to
be
tested
in
the
air
and
drop
event,
and
maybe
that
helped
jump
start
some
of
the
development
efforts
that
or
people
hopefully
just
need
to
find
the
time
anyway.
A
That
was
it.
I
just
want
to
bring
this
up
as
a
nagging
reminder
for
all
of
us,
myself
included
to
start
taking
this
a
little
more
seriously,
because
we
got
to
start
making
some
progress
here.
Okay,
any
comments
am,
I
am
I
off
base.
Is
this
completely
insane
for
me
to
head
down
this
path?
Just
looking
for
feedback
here
and
how
we
can
speed
things
up
here?
I.
G
G
I
think,
ultimately,
what
will
help
is
once
we
are
a
little
bit
further
ahead
of
having
some
mechanics
working
is
to
do
what
we
did
for
cloud
events
in
the
beginning,
like
the
airport
scenario
thing
where
we
can,
we
can
probably
go
and
just
take
that
same
basic
scenario
and
just
and
just
make
it
extended
with
that
functionality
I
mean
we
probably
don't
have
to
use
the
same
the
same
code,
but
we
don't
have
to
introduce
a
new
scenario.
I
think
that
was
that
was
pretty
nice
yeah.
A
I
do
I
like
the
idea
of
extending
that
one.
Just
in
case
you
guys
haven't
looked
at
it
or
if
you
don't
remember,
we
did
actually
have
very
concrete
sort
of
high
level
scenario
in
mind.
For
example,
the
circular
discovery
endpoint
kind
of
thing
it
just
never
panned
out,
and
I
think
it's
because
it
was
still
a
little
too
abstract
so
clement.
I
do
like
your
idea,
then
to
make
it
more
concrete,
go
back
to
our
airport
scenario
and
I
think
in
fact
the
other
doug
did
ping
us
over
a
vacation.
A
G
G
A
These
endpoints
are
out
there
to
play
with
I'm
not
sure
how
far
along
they
are.
I
think,
for
example,
scott's
has
all
local
urls
for
things,
so
you
can
use.
Subscribers
may
not
necessarily
work
stuff
like
that,
but
some
of
them
are
different
stages,
so
give
it
a
try.
Okay,
anyway,
that
was
it.
It
was
more
of
a
nagging
thing
more
than
anything
else.
A
Okay,
before
we
adjourn
just
a
question
for
you
guys
going
back
to
the
entire
discussion
that
around
this
stuff,
I
love
today's
phone
call
right.
I
think
diving
deep
into
walking
through
very
concrete
examples
like
this
are
going
to
help
expose
gaps
in
our
design
and
our
thinking
do
you
th
the
weekly
phone
call.
Is
the
appropriate
spot
to
have
this
discussion
or
do
we
need
to
set
up
a
dedicated
like
possibly
two
hours
or
more
dedicated
time
to
have
a
deep
dive
virtual
whiteboard
session?
A
G
This
is
the
this
is
the.
I
think
this
is
the
thing
where
we're
really
missing
the
the
face-to-face
conference
meetings,
because
that's
why
you
would
hatch
that
sort
yeah,
so
yeah.
I
think
I
think,
given
that
it's
unlikely
that
we're
gonna
have
that
this
year
to
be
realistic,
we
should
go
and
and
figure
out
how
we
can
go
and
do
a
virtual
face-to-face
with
lots
of
time.