►
From YouTube: CNCF Serverless WG 2020-11-05
Description
CNCF Serverless WG 2020-11-05
B
C
I
guess
that
explains
why
he
was
rolling
off
stuff.
I
didn't
know
yeah.
A
I
I
didn't
know
whether
he
stepped
down
as
director
because
of
that
or
executive
director,
because
of
that
or
whether
he
was
you
know,
looking
for
something
else
to
work
on
or
whatever
yeah
he's
sad,
he
didn't
he
seemed
to
well.
I
guess
age
is
relative,
but
I'm
getting
up
there,
but
he
didn't
seem
that
old.
C
C
That's
the
one
on
schema
or
registry
replication.
A
C
Okay,
I
just
had
a
question
on
one
of
the
comments
that
you
made
and
regarding
the
epoch,
I've
been
gone
for
a
few
weeks,
so
I
wasn't
sure
if
that
was
still
open.
I
was
I'll
ask
when
you
guys
cover
that
okay
yeah
sounds.
C
E
E
A
C
A
A
Okay,
just
curious
because
I'm
still
in
my
wife's
monitor
today
so
and
I
always
thought
it
was
a
better
resolution,
but
I
could
never.
I
never
knew
whether
the
monitor
actually
influenced
what
you
actually
shared,
because
it
would
seem
weird
to
me
that
it
would
influence
it
that
much,
but
maybe
it
does.
C
So
first
thing
you
need
to
upgrade
your
monitor
and
the
second
part
I
don't
know
if
the
monitor
makes
a
difference.
I
have
a
4k
that
people
complain
about
that.
I
have
to
change
it
every
time
I
share.
A
Well,
yeah,
that's
a
different
issue.
Yes,
that
is
true.
I
know
I
know
that
in
the
resolution
will
change
depending
on
the
monitor,
that's
for
sure,
but
I
didn't
know
whether
the
actual
christmas
would
change
as
well.
I
guess
I
guess
they're
kind
of
they
could
be
related,
so
never
mind
all
right,
hey
christoph.
A
Hello,
so
please
let
me
know-
and
I
mentioned
this
last
week-
the
guys
working
outside
they
were
further
away
now.
They're
like
within
10
feet
of
me.
So
let
me
know
if
I
need
to
go
on
mute
more
often,
but
if
you
guys
don't
hear
the
banging
I'm
going
to
be
blown
away,
but
let
me
know:
hey
tamer,.
B
C
E
G
A
C
E
A
D
A
Redheads
I'm
like
from
like
16.,
okay,
perfect,
thank
you.
Somebody
else
jumped
in
there.
A
G
A
I
think
I
did
everybody,
okay
cool,
all
right,
let's
jump
right
into
it.
Okay
skip
the
ais
anything
from
the
community.
People
like
to
bring
up
that's
not
on
the
agenda.
A
Okay,
just
a
reminder:
we
have
two
office
hours
for
kubecon,
we'll
be
looking
for
volunteers.
Please
reach
out
to
me.
If
you're
interested
or
can
join
the
the
session
okay
this
week,
we
will
have
a
discovery,
interrupt
call
after
this
call.
As
soon
as
this
one
ends,
we
do
have
some
topics
discussed
there.
So,
if
you're
working
on
implementation,
please
try
to
join.
A
If
you
can,
in
particular,
I'm
curious
to
know
about
whether
people
are
running
the
same
spec
issues
that
I'm
running
into,
and
I
don't
want
to
do
prs
if
I'm
the
only
one
seeing
them
tumor
anything
from
the
workflow
subgroup.
I
I
So
it's
going
to
be
version,
0.5,
that's
what
we
decided
and
then
we're
from
then
I'm
going
to
work
on
a
one
hour
release,
hopefully
within
the
next.
I
don't
know
how
many
months.
A
A
Okay,
in
that
case,
this
one's
from
jim
and
he's
not
on
the
call.
This
is,
I
think,
it's
a
synthetical
thing,
just
adding
it
to
the
list
of
protocol
bindings.
I
just
I
guess
I
don't
know
why
I
hesitated,
but
I
did
anybody
see
any
reason
why
this
should
not
be
added
to
the
list
of
protocol
bindings.
A
J
Oh,
this
is
I
this
is
to
use
the
protobuf
part
even
format
in
the
websocket
protocol,
binding.
F
K
A
All
right,
oh
clements,
you're
on
good,
I
was
hoping
you
joined,
so
you
could
talk
to
this
one.
I
was
also
hoping
I
would
now
this
one.
I
think
people
will
need
more
time
to
review
it.
So
maybe
you
just
quickly
intro
it
for
people.
H
Yeah,
that's
that's
what
I
wanted,
so
what
this
does
is
it
adds
replication
to
a
replication
model
to
the
schema
registry,
which
is
something
that,
since
we
have
already
implemented,
this
is
something
that
arose
in
our
world,
and
so
I
want
to
share
this.
H
We're
going
to
read
this
from
the
bottom
to
the
top.
Okay.
H
There
you
go
not
quite
that
that
long,
okay,
all
right
so
here
there
are
two
events
that
I'm
adding,
which
are
there's
a
delete
event
and
there's
an
update
event,
and
so
they
will
so
that's
the
first
time.
I
think
we
define
cloud
events
and
cloud
events
unless
there
is.
There
are
events
already
in
the
discovery
spec,
but
I'm
basically
I'm
basically
having
two
events
for
state
changes.
H
The
update
is
really
an
upstart,
but
I
I
just
want
to
keep
that
simple,
and
what
that
does
is
it
indicates
the
source
is
always
the
base
uri
of
the
schema
registry.
That's
raising
it.
So
that's
that's
also
the
way
you
subscribe.
H
So
when
we
go
in
and
register
a
schema
registry
in
discovery,
then
the
subscription
from
the
subscription
endpoint
would
basically
also
be
that
the
event
type
is.
Then
you
know
the
update
or
the
the
delete.
I
have
about
a
typo
in
the
second
one
in
delete
that
should
be
delete
and
then
the
subject
is
the
object
that
has
been
created
or
updated.
So
that's
effectively.
We
have
this
this
path
hierarchy.
H
If
you
remember
schema
groups,
the
name
of
the
schema
group
and
then
schemas,
the
name
of
the
schema.
H
H
There
would
be
no
body,
and
the
reason
for
that
is
that
those
objects,
particularly
these
shape
schema
documents,
might
be
quite
large
and
they
might
exceed
our
assumed
maximum
size
that
we
set
of
of
64k
for
per
event.
So
the
assumption
here
is
that
and
that's
a
line
also
lined
with
with
guidance
that
we
give
customers
for
for
these
kinds
of
notifications.
H
Attach
that
document,
the
use
case
for
these
events
is
that
you
can
is
replication
that
you
have
a
registry
so
think
you
have
a
event
broker
that
is
connecting
to
another
event
broker
in
in
kind
of
a
replication
in
a
replication
model.
So
you
have
a
event
broker
that
you're
publishing
to
in
in
one
application,
and
then
you
have
another
application.
H
That
hasn't
also
has
an
event
broker
and
you're
replicating
events
between
those
two,
of
course,
and
then
assume
that
the
publisher
to
the
first
event
broker
can
only
see
its
event
broker
and
the
consumer
from
the
other
event
broker
can
only
see
its
event
broker,
which
means
they
might
not
have
access
to
the
schemas,
which
means
along
the
replication
path.
For
the
events.
H
We
also
need
to
be
able
to
go
and
replicate
events,
the
schemas,
and
so
what
this
will
do
is
it
will
allow
the
the
event
brokers
to
subscribe,
to
schema
changes
amongst
each
other
so
that
they
can
go
and
effectively
replicate
the
schemas
between
them
and
then
I'm
describing
in
this
spec
describing
further
rules.
So
when
you
establish
such
a
relationship,
what
you
would
do
first
is
that
the
subscriber,
which
I
call
the
target,
would
first
go
and
walk
up
to
the
source
right.
H
The
source
registry
traverse
the
object
graph
and
basically
grab
whatever
schemas
that
are
available
within
the
schema
group
or
the
entire
registry,
and
then,
whenever
there's
a
schema,
whenever
there's
a
state
change,
it
will
go
and
be
notified
and
then
would
go
and
grab
the
delta
as
the
the
the
events
indicate
now
we're
introduced.
So
with
this
we're
now
introducing
now
scroll
up.
H
All
the
way
to
the
top
of
top
of
the
changes
yep
there
is
a.
H
Because
I'm
introducing
somewhere
I'm
introducing
the
the
notion
of
an
authority
to
the
authority
right
here.
Yes,
okay,
that's
the
key
piece
that
requires
a
bit
of
of
explanation,
so
so
the
registry
that
we
have
right
now
is
one
that
that
works
nicely
locally.
H
So
you
have
one
schema
registry
that
is
effectively
for
one
event
broker
and
that
works
for
you
know
anything,
that's
that's
local
to
it
and
it
has
no
notion
of
foreign
or
local
things.
It
you
store
schemas
in
it
and
you
get
the
you
get
schemas
from
it
if
we're
creating
these
sort
of
federations.
So
if
we
have
these
event
brokers,
where
we're
now
doing
effectively
these
forwarding
routes,
we
need
to
have
a
clear
notion
of
what
the
home
is
for
for
particular
schemas
and
who
owns
them.
H
So
there's
the
simple
case
of
that.
I
just
described
simple
in
the
sense
of
of
a
straightforward
use
case
where
you
have
broker
a
broker
b
and
those
two
need
to
go
and
talk
to
each
other,
and
so
you
need
to
have
a
disambiguator
between
those
two
on
who
owns
which
schemas
and
then
there's
a
more
sophisticated
case.
Where
you
might
have
a
central
central
schema
registry,
which
means
you
are
in
in
you
know,
a
big
bang
or
a
big
healthcare
provider,
and
there
someone
has
the
job
of
being
the
god
of
all
schemas.
H
H
But
you
really
want
to
have
your
registries
in
a
infrastructure
that
can
go
and
cache
them
probably
hold
them
in
memory
and
give
them
out
as
quickly
as
you
can,
without
necessarily
having
a
dependency
on
that
big
central
store.
So
replication
is
something
that
you
will
want
so
so
we
have
these
k,
so
we
have
cases.
Where
effect
we
have
a
publisher
authority,
as
I
call
it
or
producer
authority
where
the
producer
has
some
schema,
that's
embedded
in
their
code
and
as
they
are
as
they're
publishing
the
first
schema.
H
They
will
go
and
publish
the
schema
into
the
registry
and
that
that
that
schema
will
flow
along
the
event
replication
path
and
be
propagated
into
other
registry,
so
that
the
consumer
ultimately
gets
it.
In
that
case,
the
producer,
the
authority,
is
really
the
producer
uri
that
represents
that
producer,
and
you
have
the
central
authority
case
where
the
authority
is,
you
know
whoever
the
center
of
registry
uri.
That
represents
the
central
registry.
H
H
That's
that
idea,
and
so
the
authority
becomes
a
central
concept
here
for
disambiguation,
where
you
can
now
go
and
merge
schemas
from
many
authorities
into
one
schema
registry
and
the
distinction
between
between
those
is
that
schemas
that
are
from
foreign
authorities
are
read.
Only
you
can
only
watch
them
and
you
can
use
them,
but
you
can't
edit
them,
and
you
can
only
edit,
your
and
and
append
and
change
your
the
the
the
the
the
schemas
that
are
under
your
own
authority.
H
Otherwise,
you,
I
think
it
would
make
sense
for
you
to
go
and
read
this,
and
we
believe
that
that's
a
model
to
allow
you
know
multiple
domains
to
kind
of
arrive
in
a
common
pool
of
schemas
and
and
share
them
in
these
kind
of
integration
scenarios,
which
we
will
certainly
have
a
lot
with
cloud
events
and
and
ultimately,
I
don't
think
we're
going
to
have
the
central,
the
grand
central
schema
registry
in
the
sky,
but
but
mostly
every
eventing
service.
H
Every
eventing
infrastructure
will
have
its
own
registry,
if
only
for
reasons
of
decoupling
and
and
every
in
all
the
the
schemas
that
are
landing
in
a
registry
through
replication
from
from
different
authorities
are
effectively
sitting
there
as
a
cache
and
because
because
we
have
the
principle
here
of
making
schemas
immutable,
the
cache
management
is
very
easy
because
you
can
only
go
and
add
and
things
effectively
never
expire
because
the
versions
standard,
the
a
version,
is
stable.
H
A
H
It's
like
it's
like
xml,
namespaces
same
same
principle,
it's
a
name
that
ultimately
the
one
of
the
biggest
problems
we
have
in
this
in
the
entire.
You
know
one
of
the
biggest
problems
we
have
with
the
internet.
H
One
of
the
unfortunate
things
is
that
we
don't
have
a
euro
a
url,
a
ui
scheme
which
is
useful
for
just
hey.
This
is
an
identifier,
because
urn
is
unfortunately
weird
so
http,
I'm
just
using
http
here,
but
it's
really.
It's
meant
to
be
an
identifier,
so
this
https
schema.schemas.corp.example.com
is
really
just
a
name.
A
H
H
If
I
have
not,
I
have
not
made
this.
I
have
not
made
this
explicit
or
haven't
really
made
a
hard
rule
around
this.
H
A
H
Yeah
that
would
have
that
would
have
to
that
would
have
to
exist.
Ultimately,
I
think
a
schema.
I
think
a
registry
needs
to
have
a
notion
of
what
is
coming
from
the
outset
and
what
is
local
right?
Okay,
cool!
Thank
you.
So
there
is
a
I'm
writing.
I'm
writing
that
there.
If
this,
if
the
authority,
if
you
scroll
up,
I
think
down
to
authority,
go
to
the
actual
attribute.
H
Down,
oh
there,
we
go
yes
here
for
schemas
imported
from
other
registries
and
applications,
and
there
is
the
attributes
required
to
be
not
empty,
that
the
value
is
empty
or
absolutely
very
important
must
be
explicitly
set
to
the
to
its
implied
default
value
and
the
implied
default
value
is
the
base
uri
of
the
api
endpoint.
So
that's
kind
of
what
I'm
saying
like.
If
you
don't
have
one.
If
you
haven't
set
this,
then
it's
this
it's
this
network
address.
C
No,
I
did,
but
I'm
I'm
changing
my
thoughts
now
either
go
back,
go
back
and
reread
based
on
clemens
talking,
okay,
cool.
C
No,
I
was
reading
some
comments
in
terms
of
uniqueness
and
trying
to
identify
changes
and
I
need
to
go
back
and
think
about
it
again.
I'm
gonna
go
back
and
re-read
it
again
then
I'll
come
back.
I
don't
think
we're
meeting
next
week
we're
meeting
the
week
after
is
that
right.
Are
we
yeah.
C
Are
we
not
meeting
next
week?
What's
up,
I
wasn't
sure
for
some
reason
I
thought
that
was
off
the
schedule.
Maybe
it
was
just
my
calendar.
We
may
be
missing
kubecon,
but.
C
Okay,
my
dates
are
off
then
I'll
I'll
make
my
comments
in
the
pr
for
next
week.
Yes,.
H
G
H
Klaus
had
made
a
comment
in
the
chat
that
he
would
find
that
authority
model
potentially
also
useful
for
for
discovery.
H
A
A
The
biggest
change
here
is,
let
me
do
this
instead,
basically,
what
he
did
was
you
had
the
id
as
a
query,
parameter
on
all
these
operations
yeah,
and
he
wanted
to
be
part
of
the
path
instead,
and
I
think
there
are
other
people
who
would
agree
with
that
change.
Did
you
have
a
strong
feeling,
one
way
or
the
other.
F
H
F
F
F
Near
the
bottom,
I
guess
singing
together,
yeah
queering
for
list
of
subscription.
There
you
go.
Oh
yeah.
F
L
A
H
What's
there's
here.
H
Yeah,
I
think
I've
which
I
was
I've
just
been
a
little
cheap
here
in
terms
of
the
the
number
operations,
because
I
think
what
you
now
have
is
you
have
subscriptions
a
plain
get
on
subscriptions,
gives
gives
you
multiple
and
then
you
do
subscription
slash
id,
and
that
gives
you
the
the
particular
subscription-
and
I
think
I
just
had
had
those
operations
collapsed
into
one.
H
If
I
have
I'm
fine
with
that
change,.
A
H
Yeah
yeah
yeah,
I
think
that's,
I
think,
that's
fine
and
I'm
not
necessarily
always
self-consistent.
So
this
is
a
welcome
correction
and
that
also
that
makes
sense.
H
F
Okay,
a
nice,
your
hands
up,
yeah.
I
was
just
wondering
because,
in
order
to
be
consistent
in
discovery
like
weren't,
we
also
trying
to
find
out
ways
to
query
discovery
collections.
A
A
A
Okay,
now
during
objection,
I
personally,
I
would
prefer
to
get
it
in
not
because
I
think
it's
it's
the
best
thing
that
we
that
we
can
do,
but
rather
that
change
of
moving
into
the
path
is
something
that
I
know
everybody
working
on
the
interop
stuff
wants,
so
it'd
be
nice.
If
we
were
if
the
specs
were
consistent
with
what
we're
actually
implementing
so
last
chance,
any
objection
to
a
proofing.
A
A
I
didn't
see
well
ignore
the
typo
in
there.
I
did
not
see
a
way
for
a
subscriber
to
know
what
filtered
dialects
were
actually
supported.
The
specific
only
talks
about
the
basic
one,
but
it
does
imply
that
you
can
define
other
ones,
so
I
thought
it'd
be
nice.
If
the
discovery
api
told
us
what
dialects
were
actually
supported,
so
I
wanted
to
add
a
field
there
now,
scott.
I
think,
on
the
on
the
interrupt
call
we
had
on
monday
suggested
rather
than
repeating
repeating
the
word
subscription
everywhere.
A
Here
we
just
say,
dialects
and
config
and
stuff
like
that
which
we
could
definitely
do.
I
don't
have
a
strong
feeling
about
that,
but
I'd
rather
do
that
as
a
separate
pr.
That
way,
we
get
multiple
things
at
the
same
time,
but
for
right
now
I
just
called
the
angular
typo
subscription
dialects
with
a
list
of
dialects
in
there
and
it
is
optional.
A
Okay,
next,
so
I
just
define
it
down
here:
okay,
this
one
is
a
big
one,
so
I
believe,
based
upon
what
we
mentioned.
A
Okay
on
last
week's
call,
we
talked
about
how
clemens
you're
saying.
No,
this
really
wasn't
supposed
to
be
filters.
It
was
supposed
to
be
a
singleton,
but
then,
through
slack,
you
said
you
were
wrong.
It
actually
was
supposed
to
be
yes,
okay,
so
so
we
can,
I
think,
skipped
that
one
on
this
one,
the
config,
did
you
give
this
one,
any
more
thought
and
to
refresh
people's
memory.
This
was
supposed
to
be
hold
on
a
minute,
my
phone's
reading.
A
This
is
supposed
to
be
a
map
of
additional
configuration
values
for
the
subscription
itself
that
are
not
directly
related
to
the
transport,
because
we
have
a
mechanism
for
specifying
transport
things,
but
rather
this
is
a
maybe
configuration
knobs
about
the
subscription
itself
and
the
example
I
kept
giving
was,
if
you
had
a
ping
service.
How
often
do
you
want
the
ping
service
to
send
a
a
ping?
Basically,
but
there
are
other
examples
mentioned
as
well.
A
Was
that
question
for
me
yeah
just
so,
because
you,
I
think,
you're
going
to
go
off
and
think
about
this
one.
Some
more.
H
Yeah
so,
and-
and
I
think
I
think
that
those
that
does
make
sense
okay
from
and
that
is
because
of
the
the
the
configuration
effectively
of
the
of
the
subscription
of
the
subscription
reader,
I
would
say
like
in
so
in
my
head:
there's
a
source
and
then
there's
a
subscription
thing
that
kind
of
attaches
to
the
source.
H
And
then
there
is
a
you
know
the
way,
how
you
push
those
messages
out
and
that's
basically,
some
prior
art
from
opcua,
particular
in
particular,
where
you
can
subscribe
on
an
object
that
you
need
to
go
and
actively
walk
up
to
and
read
from
where
you
need
to
go.
Take
samples.
H
A
Okay,
I
had
one
the
value
I
I
believe
I
wrote
this
up
so
that
it
could
be
any
of
the
data
types
specified
in
in
cloud
events.
Basically
right
string,
integer
time
whatever,
as
I
was
coding
this
up,
I
I
can
kind
of
do
that.
That's
not
a
big
deal,
at
least
I
think
I
can
the
I'm
just
wondering,
though,
whether
that
makes
life
harder
for
people
and
whether
we
should
just
mandate
it's
a
map
of
string
to
string.
A
A
A
L
F
B
A
To
me,
this,
this
field
is
actually
used
for
on
both
ends.
I
think
it's
used
by
the
subscriber,
so
they
know
what
values
they
can
put
in
there
and
they
need
to
know,
for
example,
whether
everything
is
a
string
versus
an
integer
and
then
yes,
I
agree
the
event
producer
or
something
on
the
subscription
manager.
Side
of
the
house
will
use
this
to
determine
how
to
possibly
configure
either
the
subscription
or
the
producer
or
something
behind
the
scenes.
Because
to
me
it's
an
implementation
detail.
B
B
A
Needs
it
yeah.
Oh,
that
I
don't
know.
To
be
honest,
I
I
see
when
I
was
coding
this
up.
To
be
honest,
my
event
producer
is
the
subscription
manager.
So
it's
all
in
one.
I
don't
have
separate
middleware
right,
but
granted
it's
just
a
demo
thing
and
I
I
wasn't
sure
if
other
people
were
going
to
run
the
same
problem
where
I
need
to
somehow
know
whether
this
particular
field
is
an
integer
versus
a
string
and
parse
it
differently.
A
Trying
to
avoid
the
situation
of
hard
coding,
oh
I
know
a
field
is
called
interval.
Therefore
it
must
be
an
integer
right.
I
want
to
avoid
hard
coding
stuff
if
I
could
at
least
were
part
of
the
processing,
but
if
everybody
else
is
fine
with
saying
no,
it's
you
know
let
it
be
whatever
type
they
want,
and
the
scheme
is
going
to
tell
you
that
then
I'll
just
I'll
just
deal
with
it.
F
So
niche,
I
just
wanted
to
bring
the
point
that
we
probably
need
to
outline
the
difference
between
subscription
config
and
the
protocol
specific
settings
because
I
don't
know,
I
still
don't
see
a
clear
picture
between
or
basically
the
difference
between,
the
protocol
settings
and
subscription
config
because
they're
very
messaging,
very
system,
specific
settings
which
needs
to
be
propagated
by
the
subscriber
right
and
ultimately,
they
end
up
inside
the
they
even
producer.
So
where
do
we
draw
the
line?
A
I
think
it
is
a
valid
question.
You
want
to
open
an
issue
to
make
sure
we
come
back
and
add
some
text
around
that
and
obviously
the
result
of
that
could
be.
We
kill
off
one
of
them.
If
we
can't
have
a
clear
description
between
this
or
we
can't
have.
If
we
don't
have
a
clear
delineation
between
the
two,
then
maybe
it's
justification
for
killing
one
of
them
right.
I
don't
know,
but
it's
a
good
discussion
to
have
yes,
cool.
A
A
Okay,
let
me
actually
hide
the
comments,
make
it
easier
to
see
so
in
this
particular
or
okay.
In
my
proposal,
what
I'm
suggesting
is
filters
is
an
array
of
conditions
and
inside
each
condition
you
can
specify
not
just
the
the
type
of
the
filter,
meaning
the
dialect,
I'm
sorry,
the
dialect,
type
property
and
value
right.
So
in
this
case
we're
doing
a
basic
one,
we're
just
going
to
check
the
prefix
of
the
type
property
and
it
has
to
match
com.example.
A
Okay,
what
I
changed
here
was
dialect
was
not
inside
each
condition
before,
which
means
you
can
have
an
array
where-
and
these
are
all
added
together-
where
the
operands
for
the
and
can
actually
use
different
dialects,
and
I
think
klaus
raised
a
concern
around
that,
whether
that's
adding
additional
and
maybe
we
should
only
have
one
dialect
per
filter
grouping
which
implies
one
dialect
per
subscription,
and
I
was
pushing
back
a
little
on
that
because
to
me
once
a
subscription
manager
can
support
more
than
one
dialect.
A
I
did
not
think
it
was
a
huge
burden
to
say:
well,
you
can
do
any
of
them,
then,
as
long
as
he
knows
how
to
do
each
one
individually,
he
can
hand
them
all
together
because
it's
almost
like
a
not
recursive
but
they're
independent
processes
right.
Each
individual
condition
should
be
independent
of
the
other
conditions,
and
you
just
add
them
all
together.
So
I
didn't
see
why
we
would
need
to
restrict
it
to
one
dialect
per
filter.
H
I
agree,
I
agree
with
that.
We
have.
We
have
just
prior
art
on
that
one
we
have
in
mqp,
we
have
new,
a
new
filter,
spec,
that's
just
about
to
be
just
about
done
and
we
have
composition
filters
there
there
and
and
or
so.
This
is
kind
of
like
here,
where
we
have
as
an
and
an
implied
one
and
anything
that
fulfills
the
archetype
filter
can
be
used
there.
So
you
can
go
and
mix
and
match
between
simple
property
matches
in
sql.
H
B
All
I
did
some.
I
just
wrote
my
comment
because
I
did
some
research
on
how
originally
we
meant
this,
because
I
think
last
week
there
was
some
confusion.
I
mean
it's
just
one
filter
as
multiple,
and
I
just
wanted
to
be
sure
that
our
original
intention
with
one
filter
and
multiple
conditions
was
made
clear
and
if
we
now
decide
to
change
this,
then
okay.
So
it's
for
me.
It's
just
a
feeling
that
mixing
dialects
is
complexity.
L
My
one
concern
with
putting
dialect
inside
of
the
object
inside
the
array
of
filters
is
that
it
becomes
much
more
difficult
to
unmarshal
those
inner
objects,
because
you
have
to
do.
L
A
A
A
Subscription,
I'm
not
sure,
that's
what
he's
talking
about.
Okay,
that's
an
interesting
topic,
though.
No,
I
think
what
he's
talking
about
is
in
particular
for
go.
He.
What
scott
wants
to
be
able
to
do
is
to
be
able
to
look
at
the
dialect
and
say:
okay,
these
other
fields
are
part
of
the
basic
dialect.
A
Therefore,
I'm
going
to
pass
it
to
my
basic
dialect
on
marshaller
for
java
or
for
json,
whereas
if
I'm
going
to
come,
if
I,
if
the
dialect
is
quote
complex,
then
they
could
pass
it
to
a
different
json
on
marshaller
and
he
doesn't
have
to
basically
any
take
and
he
could
take
this
entire
sub-object
and
just
dump
it
all
into
that.
Other
marshaller.
A
L
A
It's
an
interesting
question
because.
H
I
think
I
think,
I
believe,
the
reasoning
and
and
the
the
the
you
know
we're
talking
we're
talking
about
if
we
were
talking
about
an
object
here
that
had
400
fields,
I
would
understand
the
concern,
but
really
we're
talking
about
something.
That's
relatively
easy,
even
with
other
dialects.
They're
not
going
to
be
it's
not
going
to
be
exploding
into
something
that's
enormously
complicated.
H
At
this
level,
at
this
level,
I'm
I'm
not
sure
that
that's
that
that's
something
that
would
cause
me
concern
in
terms
of
perf
to
have
the
dialect
outside
or
inside,
or
to
make
this
a
a
nested
nested
grouping
grouping
thing
there.
I
would
prefer
clarity
in
the
in
the
information
model
versus
optimizing
that
for
for
particular
implementation.
H
J
Well,
if
that
makes
you
feel
comfortable
clements,
if
you
look
at
the
pod
spec
from
kubernetes
like
if
you
look
at
volumes,
they
did
like,
like
scott
is
saying
because
of
the
limitation
of
the
golan
parser,
so
like
off
of
the
kubernetes
apis
are
then
signed
with
this
problem
in
mind.
H
Yeah,
but
they
only
need
to
be
as
fast
as
atcd
is
you
know,
but
I
have
I
if
you
guys,
if
you
guys,
really
think
that
you
need
this.
M
Personally,
I'm
torn
I'm
like
I'm,
not
I'm
not
gonna
make
anybody's
life
harder.
H
A
That's
why
I'm
torn
here
because
be
honest,
because
if
there's
so
many
things
about
goalie,
I
would
like
to
figure.
I
mean
I
love
god,
don't
get
me
wrong,
but
there
are
certain
things
around
jason
parsons.
I
would
really
love
to
fix
like
the
fact
that
he
doesn't
know
how
to
handle
unknown
properties
and
stuff
right,
but
it
it
just
seems
to
me
that
if
I
was
writing
the
spec,
you
know
I
don't
think
it's
going
to
be
a
bad.
A
A
It
was
a
list
and
the
key
value
here
was
basic
instead
of
dialect,
and
then
it
was
an
object
with
these
things.
I
could
I
could
buy
that.
H
A
I'm
not
saying
it's
right,
I'm
just
saying
I
could
I
could
buy.
I
could
buy
a
nesting
if
you,
if
you
went
down
that
path.
I
just
from
a
straight
spec
perspective,
it's
hard
for
me
to
buy
a
nesting
here,
but
I
don't
want
to
discount
completely
the
fact
that
it
may
like
make
the
implementation
harder
for
some
people,
I'm
not
sure,
I'm
sorry,
I'm
going
to
completely
give
into
it.
But
I
understand
it.
L
And
yep:
that's
that's
exactly
what
I'm
saying,
but
why
yeah,
because
usually
you're
going
to
pick
an
engine
that
you're
going
to
subscribe
to
and
I
I
think
it
would
be
interesting
to
be
able
to
have
that
subscription
broker
say.
Actually
I
only
do
regex
well.
A
H
I
A
L
C
A
Okay,
because
I
don't
want
to
necessarily
ignore
the
issue
I
would
like
to
revisit
it,
but
I
do
also
want
to
make
forward
progress.
A
Would
you
be
willing
to
hold
your
nose
for
a
while
to
to
see
how
other
people,
what
kind
of
pains
they
go
through
when
they
implement
it.
A
L
Doug
is
trying
to
start
the
tabs
versus
spaces.
A
I
swear,
I
did
not
mean
to
it
was
a
mistake,
but
I
do
have
a
very
strong
opinion
on
this,
but
I
will
I'll
save
that
for
later.
Okay,
I
think
this
is
just
textual
gorp
matching.
What
did
there?
A
Oh
yeah?
This
is
just
syntactical.
I
put
lowercase
these
because
I
think
that's
what
you
actually
meant
to
use
in
the
actual
thing
itself
and
you
might
be
able
to
get
confused
as
to
whether
these
are
meant
to
be
used
inside
of
the
json
or
not.
So
I
just
lowercase
those.
I
think
this
is
just
syntactical
sugar
cleanup.
A
M
H
What
do
I
do
here
and
you
know,
and
the
reason
why
is
as
soon
as
we
say
case,
insensitive
we're
again
in
this
case
folding
nightmare,
and
we
want
to
go
and
avoid
that.
I
think
yep.
A
Okay,
thank
you
hold
on
I'll,
get
that
okay
and
then
down
here.
It's
not
really
specky,
but
I
just
wanted
to
show
what
things
would
look
like,
especially
when
we
started
doing
the
the
id
as
the
in
the
path
inside
the
query
parameter
just
some
samples,
because
I
like
samples-
and
that
was
basically
it
any
other
question
and
I'll
fix
them
here.
Let
me
get
this
there's
an
extra
eye
there.
I
keep
forgetting
to
fix
that
any
other
questions
or
comments
on
this
one.
B
One
general
question:
yes,
and
did
we
at
some
point,
decide
to
stick
to
the
kind
of
naming
properties
that
we
do
this
like?
We
did
it
for
context,
attributes
I
mean
without
hyphens
or
without
candle
case
just
the
way
we
have
it.
Here
I
mean
in
apis
it's
more
common
to
have
something
like
camera
case
mutation,
I
think
which
properties
in
particular
you
think
subscription
euro
subscription
config,
I
mean
they
are
just
one
word
without
upper
lowercase.
Anything.
H
Okay,
the
reason
why
we
did
that
for
for
the
for
the
context
attributes
is
that
we
were
putting
these
in
http
headers
yeah.
B
H
Exactly
we
had
a
heart,
we
had
the
hard
technical
reasons
to
to
keep
it
all
lowercase.
But
I
think
here
we
can.
We
can
make
things
a
little
bit
more
normal
again
and
that's
that's
a
good.
That's
a
good
point
and
use
camel
casing.
A
Okay,
klaus,
do
you
want
to
open
up
an
issue
or
even
a
pr
to
that?
Let
me
get.
We
can
try
it
yeah
yeah,
I'm
not
hearing
anybody
object
to.
It
sounds
like
a
good
idea.
A
Okay,
clemens.
I
forgot
somebody
madison
in
the
chat
mentioned
that
I
think
right
now.
The
the
schema
dock
shows
it
as
subscription
not
subscriptions,
and
I
actually
added
the
s
here
too.
Just
as
a
coincidence,
are
you
okay,
with
an
s
with
this
being
plural.
A
A
F
F
So
I
thought
in
that
moment
we
decided
that
we
probably
don't
want
to
deal
with
anything
related
to
security
or
the
data
integrity
part,
and
that's
what
I
was
trying
to
sum,
but
I
do
see
some
important
points
being
brought
up
by
eric.
So
I'm
not
sure
whether
should
I
address
them
right
now
or
should
I
oh?
Should
we
wait
till
we
just
tackle
the
security
and
the
data
integrity
issue
in
the
future.
K
Do
you
want
to
chime
in
sure
they're
they're,
not
that
important,
but
I
was
I
was
taking
a
slight
issue
with
the
notion
of
declaring
that
those
those
matters,
integrity,
confidentiality
and
whatnot
are
not
core
to
the
spec.
I
think
they're
very
important
and
we
consider
them
such
and
it's
simply
that
we
are
not
providing
a
solution
for
those.
K
Yet
the
the
second
piece
is
that
it,
I
think
we
should
imply
that
extensions
may
exist
for
solving
these
problems
and
that
over
time
we
expect
them
to
accumulate
into
the
spec
as
unofficial
extensions,
and
that
will
visit
well.
I've
described
in
my
comment.
F
So
do
we
want
to
accommodate
these
things
right
now,
because
I
thought
like
from
the
issues
and
clements
could
probably
also
pitch
in
in
the
issue.
We
said
that
we
probably
don't
want
to
deal
with
the
security
business
as
of
now.
So
that's
that's
what
that
was
one
of
the
reasons
why
I
was
behind
the
statement
of
that.
It's
not
the
core
intention
at
the
moment.
K
Yeah,
but
by
deal
with,
I
think
the
intention
is
that
we
don't
want
to
specify
a
concrete
solution.
K
K
A
E
A
J
Do
we
really
need
the
part
from
we
leave
it
up
to
the
implementer
of
the
spec?
To
the
end,
do
we
really
need
that
part?
J
F
A
So
let
me
turn
the
question
around.
Oh,
I'm
sorry
we're
out
of
time.
I
don't
want
to
rush
this
one.
I
know
it's
just
the
primer.
It's
not
normative
text,
but
I
also
don't
want
to
rush
it
either
way.
So
why
don't
we
tee
this
one
up
for
next
week
and
take
the
comments
to
the
to
github
itself
so
quickly?
Did
I
miss
anybody
for
the
roll
call?
A
Okay,
in
that
case,
please
stay
on
the
line
if
you
can
or
you're
interested
in
the
interop
work
that
we're
doing
and
we'll
talk
to
everybody
again
next
week.
Okay,
thank
you,
everybody!
Well,
we'll
start
the
next
column,
I've
been
about
a
minute
or
so.
A
I
have
to
vanish:
oh
okay.
Well,
in
that
case
clemens
before
you
go,
I'm
not
going
to
ask
you
to
answer
it.
Take
a
look
at
this
section
down
here.
I
started
adding
some
questions
earlier
today,
as
I
was
doing
the
implementation
I'd
like
to
get
your
opinion
on
them,
just
whether
we
should
change
the
spec
to
deal
with
these
things.
Just
you
can
read
them
later.
Nothing,
critical!
Let's
keep
waiting,
okay,
bye,.
L
I
had
an
ai
to
implement
it,
but
clemens
went
and
one-upped
me
with
an
actual
specification
for
it.
A
Oh
see,
I
thought
you
were
going
to
actually
add
it
to
the
spec.
A
C
A
Okay,
let's
see
we
can
go
ahead
and
get
started.
A
Okay,
I'm
not
sure
where
how
you
guys
want
to
tackle
this
okay,
so
we
we
addressed
this
one
and
it
was
yes,
okay,
so
I
had
a
question
for
you
guys
should.
A
A
L
L
Well,
so
take,
for
example,
the
github
events.
A
That's
interesting
because
in
that
model,
you're
assuming
each
subscription
to
github
has
a
different
secret.
They
should
well.
You
may
not,
though,
right
because
I
may
say
I
I
have
five
different
subscriptions,
but
I'm
just
going
to
use
the
same
token
secret
or
what's
called
across
all
of
them,
because
it's
mine.
L
L
You
want
to
know
when
the
web
hook
hits
the
distributor
which
which
of
those
consumers
is
intended
to
get
this
event,
because
I
don't
want
to
fan
it
out
to
everybody
that
doesn't
have
the
scope
for
this
particular
event.
A
L
It's
gonna
take
a
minute.
You
can
move
on.
N
Yeah,
so
I
think
regarding
the
github
signature
secret
that
it
can
be
used
to
encrypt
a
token-
and
this
is
so-
you
won't
wouldn't
find
the
secret
in
the
message,
but
isn't
what
we
are
looking
for
here,
the
same
as
a
correlation
token,
and
that
is
application
specific,
because
the
subscription
protocol
would
have
an
idea
of
managing
the
subscriptions
and
when
they
are
all
multiplexed
on
the
same
channel.
N
The
events
I
mean,
then
this
is
is
something
that
the
subscription
protocol
or
the
the
user
of
it,
chooses
to
do
or
keep
it
separate
right.
If
I
wanted
to
have
them
separate,
I
could
use
separate
transports
for
my
subscriptions
separate
transport
channels
like
separate
connections.
L
We
point
it
back
at
the
same
ingress
point,
but
we
use
different
secrets
when,
when
we're
doing
the
handshake
with
the
subscription
to
github
and
then
on
the
on
the
webhook
side
on
the
ingress
to
the
cluster,
we
look
at
this
webhook
signature
to
figure
out
which
user
created
the
actual
subscription
for
from
github,
so
that
we
can
route
it
to
the
correct
kinds
of
triggers.
L
Limitation
that
you
have,
then
you
should
route
it
to
a
different
consumer
right
for
small
numbers.
You
can,
you
could
calculate
which,
which
is
the
secret
intended
form.
A
A
So,
let's,
let's
keep
it
in
the
k
native
world,
let's
say
the
same
user
in
the
same
name:
space
in
k
native
sets
up
two
different
github
event:
sources,
both
pointing
to
the
exact
same
github,
exact,
same
repo,
but
just
two
different
in
essence,
web
hooks
and
and
now
that
that
that
namespace
or
the
you
know,
the
sync
in
that
namespace
now
gets
two
streams
of
events,
basically
and
and
that
sync
wants
to
stop
one
stream.
A
N
When
I
was
discussing
the
signature
stuff
with
alex
alex
collins
from
nuts
from
sorry
so
when
I
was
discussing
this,
the
I
think
the
actual
distinction
should
be
made
in
the
url
that
you
put
in
github.
So
if
you
want,
you
can
have
the
same
url
target,
but
you
can
append
query
parameters
to
make
a
difference
and
the
same
could
be
used
for
authentication.
N
So
when
you
want
to
have
what
is
the
the
http
callback
binding
for
cloud
events
from
used
from
github
with
authorization-
and
I
think
that
was
also
clemens
point-
is
that
you
have
to
use
the
query
parameter
of
the
out
specification.
N
A
I
I
like
that
idea,
and
I'm
I'm
mad
at
myself,
that
I
didn't
think
about
that,
because
that's
something
we've
done
in
the
past
it
just
it
completely
eluded
me.
Did
people
agree
that
that's
a
that's
the
way
to
solve
it.
Rather
than
introducing
a
brand
new
field,
someplace
just
say
no
give
us
a
unique
identifier.
Someplace
in
the
url,
probably
a
query
parameter.
A
No,
no!
No,
but
that's,
but
that's
if
someone
says
how
do
they
if
someone
walks
up
and
asks
exact,
same
question,
I
did
our
standard
answer
would
be
something
like
this
and
maybe
in
the
primary.
We
can
talk
about
that,
but
I
don't
think
I
agree
we
won't.
We
don't
need
anything
formal
and
respect
to
say
to
to
change
to
support
it.
L
L
Right
worst
case,
you're
dealing
with
some
sort
of
middleware
and
then
the
source
is
not
the
actual
source
of
where
the
event
is
coming
from
or
the
subscription,
and
then
it's
confusing.
But
that's,
I
think
you
have
to
be
aware
of
how
your
topology
is.
B
A
I
think
my
other
question
here,
I'm
trying
to
remember
why
I
even
wrote
this.
So
what
I
what
happened
to
maybe
even
think
of
this,
I
was
basically
wondering
whether
there's
something
in
the
discovery
endpoint
entry
for
a
service,
whether
it
needs
to
include
the
source
value
so
that
when
the
event
gets
received
by
the
sync,
it
will
know
what
source
value
to
expect,
and
I
don't
know
why
I
even
thought
about
that.
But
if
no
one
can
chime
in
to
say
hey.
That
sounds
like
a
good
idea.
A
C
A
When
you
say
the
workflow
spec,
I'm
not
talking
about
not
or
or
doing
or
and
stuff
like
that
between
events,
so
this
is
all
within
one
event,.
F
See
I
mean
these
are
like
really
complex
filter
operations,
so
there
will
be
cases
down
the
line
where
you
would
wanna
have
an
aggregated
filter
criteria,
not
just
one
filter
right.
So,
like
combination
of
two
filters
in
an
hand,
criteria
with
combination
of
one
filter
with
those
two
in
all
criteria,
so
we
would
have
because
the
filter
object
is
an
array.
So
you
would
probably
want
to
also
support
an
operator
on
the
line
for
sure,
but
it
would
definitely
get
messy.
L
L
Yes,
you're
right
right.
That
would
solve
your
problem
and
not
complicate
the
spec.
N
I'll
take
a
look
at
that,
so
we
made
the
default
filter
language
jsonpath,
because
we
think
of
all
the
workflow
data
being
passed
around
as
json
like
structures.
B
Yeah,
what
about
something
more
specific
for
the
source
I
mean
it's
a
uri
and
just
simple,
prefix
or
suffix
is
not
always
sufficient.
If
you
want
to
filter
your
eyes.
A
Well,
just
getting
slightly
different
topic
other
possible.
L
A
A
A
Okay,
that's
interesting,
okay.
This
question,
I
think
we
already
answered
on
the
call.
People
are
okay,
with
keeping
it
generic
types
instead
of
just
string
to
string
for
config,
okay.
So
those
are
the
questions
I
had
for
you
guys.
So
thank
you
for
helping
me
with
those.
A
Does
anybody
else
have
any
questions
they
want
to
bring
up
or
topics
they
want
to
bring
up,
I
did
add
is,
I
did
add
my
discovery.
Endpoint
out
there.
It
has
one
service
inside
of
it.
I've
not
tried
time
to
go
and
implement
the
new
specs
that
got
landed
today,
yeah
I'll
try
to
merge
those
today.
I
think
mine
actually
does
implement
the
filter
stuff
using
the
pr
we
just
approved
today,
and
I
think
it
seems
to
work
anyway.
My
quick
test.
L
I
never
got
anywhere
past
the
dummy
data
that
I
have
so
I
I
need
to
go
and
make
up
some
services
that
you
can
subscribe
to
and
get
silly
events.
Okay,
yeah!
I
just
have
the
ping
service.
A
L
Doug,
what
if
we
do
like
an
open
call
to
you
know,
interact
with
this
stuff,
so
we
make
it
like
a
blog
post,
and
we
say
here,
here's
all
these
event
sources
and,
like
one
section,
is
it's
an
open
call
to
anybody.
That's
exploring
this
to
go
and
interact
with
these
things.
A
Sure
I
feel
like
we
probably
need
to
be
a
little
bit
further
along
with
our
implementation,
so
before
we
do
that-
oh
yeah,
of
course,
of
course
yeah
but
yeah.
No,
I
like
the
idea.
F
F
F
A
We
can
I'm
okay
with
that.
Can
you
guys
do
noon
easter
on
mondays
on
a
regular
basis.
A
N
Yeah
I
wanted
to
ask
about
subscriptions
filtering
because
I
think
in
the
original
or
in
some
place
it
says
filters,
like
rate
limiting
and
so
on.
This
goes
all
into
subscription
parameters
and
they
are
subscription
protocol
specific.
But
I
wondered
if
anybody
knew
a
filtered
dialect
that
would
allow
rate
limitation.
N
A
thought
or
a
subscription
api
subscription
protocol
that
does
rate
limitation.
I
know
some
database
stuff
allows
this
some
query
languages,
but
not
the
kind
of
event
subscription
that
I
usually
work
with
so.
N
L
N
Yeah
I
was
checking
web
sockets
and
I
think
there
is
an
itf
draft
on
rate
limits
for
headers
in
http,
but
I
don't
see
that
going
anywhere.
Also,
it's
in
section
three
two
one
subscription
object.
N
Yeah,
that's
that's
where
it
is
currently
yeah
protocol
settings.
N
F
I
mean
that's
a
very
dispatcher,
specific
property
or
attribute
right,
so
this
is
something
which
again,
I
agree,
will
go
the
protocol
settings
the
subscription
conflict,
one
of
the
twos,
so
that
basically
the
dispatcher
is,
is
aware
about
what
sort
of
throughput
it
needs
to
be
considering
in
dispatching
those
events
to
the
subscriber
right
yeah.
I
don't.
L
N
Yeah
the
interesting
idea
I
had
was,
if
you
took
the
timestamp
and
you
would
box
it
into
intervals
of
one
minute
or
whatever,
and
then
you
say
that
okay
you'd
only
want
the
the
first
or
singular
occurrence
in
every
of
those
sort
of
could
be
expressed
as
a
filter.
If
there
was
a
dialect
for
it,
but
okay,
if
there
is
no
dialect,
no
language,
then
protocol
settings.
It
is.
A
I
am
kind
of
curious
with
this
use
case,
though,
because
I,
I
could
definitely
understand
it
being
a
transport
level
concern,
but
I'm
also
wondering
whether
there
are
other
use
cases
where
it's
not
a
transport
level
thing,
but
it
actually
is
on
the
event
producer
side,
because
maybe
you're
asking
him
to
use
this
interval
to
query
the
system
to
get
the
current
state
and
send
that
out
as
an
event.
N
A
L
But
I
think
the
point
is
that
it's
not
necessarily
specific
to
the
events
that
are
flowing
through
that
broker,
but
it's
the
subscription
that
you've
asked
that
broker
to
do
for
you
and
so,
regardless
of
the
what
the
event
shape
is
and
what
you
want
to
filter.
You
could
put
additional
requirements
on
the
broker
for
this,
but
how
to
handle
this
particular
subscription
and
that's
where,
like
qps
or
rate,
limiting
or
maybe.
A
L
L
Right
so
you
said
you
make
it,
you
know,
I
I
have
some
wacky
subscription
broker
that
the
protocol
setting
says.
I
only
want
one
request
a
second,
but
I
have
a
bursty
subscription
producer
on
the
other
side,
it
could
cue
and
only
push
one
event
to
me
at
a
time
because
that's
a
feature
of
that
broker,
not
a
requirement
of
the
subscription.
A
Very,
very
great,
no
I
I
agree.
I
I
I
guess
what
I'm
saying
is
I'm
wondering
if
we
just
whether
we
just
need
to
make
sure
we
can
support
both
scenarios,
one
where
you
are
strictly
modifying
transport
level,
semantics,
whether
it's
done
by
the
subscription
manager
or
it's
done
by
some
middleware
like
you're
talking
about
scott,
but
then
there's
also
the
use
case
of
the
producer
itself
needing
to
say,
I'm
only
going
to
send
an
event
once
every
five
minutes,
because
that's
what
the
person
asks
for.
I.
L
Have
a
new
way
to
to
talk
about
this
one
way
to
think
about
it
is,
I
think,
it's
probably
okay
with
the
spec,
if
you
add
this
rate
limit
filter,
but
in
that
case,
if
it's
a
subscription
filter,
it
will
drop
events
that
occur
during
a
that
window,
that
you
don't
want
events.
So
if
you
only
want
one
event
every
minute
and
you
have
a
producer,
that's
producing
once
a
second
you're
gonna
drop
59
events
and
only
get
one.
L
A
Right
and
that's
what
I'm
trying
to
get
to
is,
I
think
there
are
use
cases
for
both.
I
think
it
makes
perfect
sense
to
say
I'm
going
to
control
things
at
the
transport
level
and
then
in
some
cases
that
will
mean
yes,
things
are
going
to
get
buffered,
but
I'm
still
going
to
get
every
event
and
then
there's
something
at
the
producers
level.
A
N
F
F
F
The
only
way
I
was
able
to
deliver
maths
was
using
using
an
http
broker,
so
all
that
kind
of
a
web
book
dispatcher
so
basically
a
side
turn
that
also
in
a
kubernetes
context,
and
that's
why
my
instrumentation
is
delayed.
F
C
F
L
L
F
C
A
A
L
Okay,
well
ping
me,
I
it's
it's
kind
of
demo
code,
so
the
subscriptions
aren't
going
to
work
the
only
one
that
works
is
for
the
discovery,
endpoint
and
this
code
might
be
super
old.
So
I
need
to
maybe
spend
this
afternoon
updating
it.
Okay,
it
actually
does
something,
but
you
can
like
hit
the
endpoints,
but
don't
expect
the
subscriptions
to
work
right
now.