►
From YouTube: CNCF Extended CloudEvents Call 2021-02-04
Description
CNCF Extended CloudEvents Call 2021-02-04
A
A
D
E
F
A
A
A
A
All
right,
it's
three
after
why
don't
we
go
and
get
started
before
we
do
that,
though,
we've
been
kind
of
just
walking
through
this
sample
scenario
with
github,
and
I
want
people
to
understand
that
this
is
just
one
that
I
threw
together.
If
you
guys
have
other
samples
or
walk
through
exercises
that
you
want
to
walk
through,
you
know,
please
speak
up
or
feel
free
to
add
it
to
the
doc
or
create
your
own
doc
or
something
I
don't
want
this
to
be
all
about
the
thing
I
find
interesting
right.
A
Okay,
let's,
let's
quickly,
though,
recap
where
I
think
we
left
off
after
last
week's
call-
and
please
speak
up
if
you
think
I
get
this
wrong
or
got
this
wrong,
we
decided
that
we're
going
to
add
a
source
property
and
it's
going
to
be
a
single
value
and
it's
going
to
match
whatever
the
source.
The
cloud
event
source
value
is
going
to
be
so
it's
kind
of
like
a
filter
in
a
sense
in,
in
the
sense
that
all
cloud
events
must
have
that
source
value.
A
It's
going
to
be
required
for
managers
to
support
optional
for
clients
to
send
it
in
on
their
subscribe
request
and
whether
this
that's
required
for
managed
or
not
is
we're
going
to
start
with
it
being
required
and
see
how
it
goes
going
forward.
I
know
there's
some
questions
about
whether
it
should
be
optional
or
not,
for
managers
to
support
it.
A
A
Okay,
similarly,
sorry
go
ahead:
yes,
okay,
cool,
okay.
Similarly,
we're
going
to
add
a
types
attribute.
It's
going
to
be
an
array
of
ce
type
values
meant
to
indicate
the
type
of
events
you're
interested
in
so
again,
it's
kind
of
like
a
filter
thing,
but
it's
no
wild
cards
or
anything.
It's
just
the
exact
values
itself
going
to
be
required
for
manager,
support
optional
for
clients
to
send
if
it's
specified
all
cloud
events
send
must
have
one
of
those
types.
A
A
We
can
figure
out
the
exact
placement
of
it,
but
we
did
actually
recently
add
a
pr
that
talks
about
this
three-step
processing
model
and
I
think
we
made
we
may
need
to
revisit
that,
not
because
it's
wrong,
but
just
to
make
it
make
sure
it's
still
aligned
with
what
we
agreed
to
up
here,
because
we
didn't
have
source
and
type
before.
So
we
may
need
to
talk
about
in
in
the
context
of
creating
the
event.
A
A
Let
me
show
you
an
example
just
so
you
guys
can
see
we're
talking
about
here
right.
So
we
have
quite
a
few
attributes
here
and
I
wanted
a
reader
of
this
to
be
able
to
specifically
say:
okay,
you
know
this
set
is
meant
for
phase
one.
This
other
set
phase
two,
and
this
other
sets
phase
three.
That's
where
there's
a
very
clear
grouping
of
these
attributes,
and
I
think
that
will
help
people
understand
how
we
envision
these
things
actually
being
used
if
they're
just
sort
of
randomly
scattered.
A
Are
an
excellent
straight
manner?
I
guess
that's
why
I
put
this
paragraph
right
here,
because
I
want
we
need
to
make
it
clear
that
these
are
our
design.
This
is
our
design
mental
model
we
had,
as
we
wrote
the
spec,
however,
how
people
choose
to
implement.
It
is
completely
up
to
them
as
long
as
it
gives
the
right
semantics.
So,
for
example,
you
know
you
could
technically
do
the
filter
during
the
create
phase.
A
If
that's
the
way,
you
chose
to
implement
it
right
and
so
we're
not
constraining
that
it's
just
I
want
people
understand
this
is
this
is
how
we
define
the
attributes
in
terms
of
how
the
end
user
kind
of
perceives
them-
and
it
is
a
little
bit
of
guidance
in
terms
of
how
we
kind
of
think
the
implementation
might
go,
but
we
are
in
no
way
requiring
that
the
information
exactly
match
that
it
does
have
to.
It
has
kind
of
appear
that
way
to
the
end
user
in
a
sense.
Does
that
make
any
sense?
G
G
So
there's
both
the
static
element
of
hooking
up
and
then
the
the
specific
element
of
filtering
for
just
the
event
of
your
interest.
Right.
So
that's
a
case,
for
you
know
same
technology,
everything
else.
It's
it's
user
configuration
specific,
whether
that
the
the
what
kind
of
type
is
going
to
be
a
a
dynamic
thing
or
a
static
thing,
and
so
I
don't
know
it
seems
like
there's
so
much.
I
mean
it's
not
bad.
G
G
Ago,
but
anyway
the
I
I
the
this
proposal
of
stages,
I
I
think
that
it's
useful
to
talk
about
that
being
an
important
part
of
what
the
systems
have
to
do.
I
I
don't
know
that
declaring
what
attributes
are
a
fit
into,
what
stages
is
something
that
you
can
do
with
you
know,
with
reasonable
confidence.
A
Oh
okay,
okay,
the
way
you
phrase
that
there
clicked
a
little
bit
better
with
me.
So
thank
you
so
so
let
me
ask
you:
let
me
pick
on
that
a
little
your
because
I
think
you're,
basically
kind
of
implying
that
something
like
trying
to
say,
source
only
applies
or
typically
only
applies
to.
The
first
phase
might
not
be
accurate,
and
I
want
to
understand.
A
Is
that
because
you
think
well
applying
the
source
property
may
actually
be
implemented
more
as
a
filter
kind
of
a
thing,
or
do
you
think
trying
to
explain
our
rationale
behind
why
source
is
pulled
out
from
the
filter
is
a
bad
thing.
I'm
trying
to
I'm
just
trying
to
figure
out
where
to
where
to
go
with
this,
because
I
think
I
think
you're
raising
an
interesting
point.
I
don't
want
to
miss
it.
That's
why
I
want
to
make
sure
I
fully
understand
it.
G
Best
at
this,
so
the
the
source
is
is
could
be
itself
a
mix
of
dynamic
and
static
pieces
right,
so
the
source
could
be.
You
know
some.
You
know
kind
of
a
whole
string
of
things,
it
kind
of
says:
here's,
the
actual
physical
component.
This
data
is
going
to
come
off
of,
but
then
it
could
also
include
maybe
the
a.
G
G
Like
a
reasonable
place
right,
but
but
that
topic
could
be
something
based
on
the
implementation,
it's
dynamic
and
that
maybe
there's
multiple
topics
or
maybe
it's
a
you-
know
a
client
to
a
specific
kind
of
I
don't
know
product
or
something
retails
poisoned,
my
brain,
but
so
you
know
there's
I
want.
I
want
all
the
events
that's
coming
from.
G
You
know
the
gucci
stream
and
so
that
that
source
could
be
both
the
stream
that
contains
this
whole
slew
of
transactions
and
events
related
to
products
for
our
company
and
then
the
gucci
part
of
that
would
be
a
filter
over
that
stream.
And
so
that's
I
I
don't
know-
and
this
is
I'm
pretty
kind
of
try.
I
feel
like
I'm
stretching
in
this
particular
case,
but
it
seems
like
this
sort
of
thing.
H
So
we
have
a
so
klaus
and
I
we're
currently
working
in
a
parallel
product
integration
stream
together,
and
we
want
to
bring
some
of
that
context
here
and
we
actually
have
a
scenario
like
this
where
or
might
have
a
scenario
like
this.
We,
where
in
no
means
by
no
means
settle
on
this
but
effectively
there
is
an
sap
system
that
wants
to
go
and
deliver
something
into
azure.
H
So
so
you
you.
Basically
you
have
a
subscription
manager
which
now,
which
is
now
acting
somewhere
over
in
the
sap
system,
and
you
say
everything
that's
being
raised
in
on
behalf
of
that
customer.
Send
that
here
that's
a
that's
a
legit,
that's
a
legit
case.
I
think,
and
the
way
how
we
would
prefer
to
model
this
at
this
point.
H
Certainly
the
microsoft
side
of
this
of
the
discussion
is
to
say
the
gucci's
scope
inside
of
that
sap
system.
That
is
a
effective
the
root
source,
if
you
will,
is
the
prefix
for
all
the
other
substructure
that
that
might
exist
in
that
system,
and
if
I
walk
up
to
that
source,
I
can
go
and
subscribe
to
everything
that's
inside
of
it,
but
that
would
still
that
would
still
say
so.
I
would
I
would
indicate
in
in
this
relationship
I
will
go
and
indicate
as
the
source
the
super
the
super
scope.
This,
like
you,
know.
H
H
I
only
want
to
have
events
from
this
more
specific
source,
which
is
prefixed
by
the
the
original
source,
and
maybe
only
this
this
type
in
this
type,
and
then
I
might
also
want
to
go
and
filter
that
further
down
to
this
subject:
prefix
or
subject
suffix
so
there's
the
kind
of
this
broader
subscription,
which
then
funnels
events
into
an
event
broker
where
you
can
then
go
and
and
have
a
second
level
subscription
to
be
more
fine-grained.
That's
that's
one
example
of
of
where
source
becomes
effectively
a
scoping
mechanism.
A
Okay,
what
I
was
going
to
say
before
was
I
I
think,
rather
than
trying
to
rat,
hold
too
much
on
this,
because
this
isn't
really
normative
text
in
the
spec.
It's
more
like
insight
into
our
thinking
process
or
how
we
expected
things
to
be
done,
but
it's
technically
non-normative
eric.
Why
don't
we
wait
until
we
actually
have
a
pr
trying
to
address
this
particular
task
or
item,
and
then
we
can
wordsmith
that
to
address
your
needs.
Does
that
sound?
Okay?
It
sounds
great,
okay,
okay
cool,
so
I
think
this
is
where
we
left.
A
A
This
is
where
it
really
starts
to
change
so
based
upon
what
we
agreed
to
the
source
now
becomes
github.com
cloud
events,
slash
spec,
and
we
have
two
types,
because
there
were
two
different
events
that
I
was
interested
in
when
I
do
subscribe.
I'll
talk
about
that
in
a
second,
but
I
have
no
filters
and
no
config,
because
all
the
config
are
now
encoded
within
the
source.
A
A
That
that's
the
that's
exact
one-to-one
mapping.
However,
the
issues
is
interesting
because
github
to
the
web
interface
just
has
the
notion
of
issues
and
you
get
all
different
types
of
issues
right,
create
versus
delete
edit.
That
kind
of
stuff.
However,
in
our
adapter
we
actually
made
the
type
to
be
github.com.github.issue.action,
or
maybe
it's
issues
I
can't
hear
for
sure,
but
anyway,
the
key
is
it's
dot
action
now.
A
H
A
A
A
H
They
don't
like
so
so
I
mean
adapter
means
means
we
take
something
that
someone
someone
built
without
thinking,
much
about
how
we're
thinking
about
events
here
and
and
we're
trying
to
adapt
it
and-
and
I
think
we
want
to
have
discrete
events
for
each
action
that
might
happen.
Okay,
I
think
from
so
so.
H
If
cloud
events
exist
and
you
would
design
this
fresh,
how
would
this
look?
I
mean
that's
what
the
adapter
should
do?
Okay-
and
I
don't
think
it
needs
to
it-
needs
to
say
here-
is
an
existing
web
api,
and
how
do
you
reconcile
that
with
with
with
cloud
events
and
preserving
it
effectively,
I
mean
we
can
do
that
and
then
the
answer
is
yeah.
A
H
Yeah
I
mean
if
we
were,
if
we
were
because
they're
not
they're,
not
they're,
not
cloud
events
compliant
at
this
point
right
and
when
they
are,
I
think
the
advice
we
would
give
them
is.
If
they
ask
you
or
if
they
ask
me,
then
you
would
say
yeah.
It
would
be
great
if
you
for
the
issues
for
every
particular
different
action
or
change
type
you
have,
you
would
go
and
raise
a
different
event.
H
J
Good
morning
yeah,
I
you
know
more
or
less
echoed
the
same
thing
right.
If
you,
if
you
look
at
it,
sort
of
a
more
restaffarian
kind
of
perspective,
they
could
still
offer
com
github
issues
that
you
have
written
as
a
fire
hose
as
well
as
the
more
fine-grained
types
or
whatever
yeah
types
that
you're
calling
it
right.
So
it
does
it.
It
doesn't
have
to
be
a
black
and
white
right
relative
to
our
spec.
A
A
K
A
Well,
finally,
so
I
agree
with
you
if
we
were
rewriting
github
from
scratch,
I
agree.
We
would
probably
put
create
it
here
right,
but
this
sample
is
trying
to
minimize
the
amount
of
changes
in
github
itself,
meaning
what
do
they
do
today
and
natively
today?
They
only
support
issues.
They
don't
support
a
finer
grain
filtering
through
their
web
book
mechanism.
Okay,.
L
A
A
K
A
K
A
A
Okay,
so
I
I
thought
it
would
be
interesting
to
see
what
would
happen
if
somebody
decided
not
to
use
types
and
they
left
it
blank,
and
instead
they
tried
to
use
filters
to
to
get
the
events
they
were
interested
in,
and
I
think
the
requests-
and
I
say
request
because
there's
two
of
them
would
look
like
this
right.
I
think
you'd
still
have
the
source
point
of
cloud
event
spec.
A
H
H
H
A
H
H
A
H
H
H
A
H
A
Sure,
okay,
so
going
back
to
here,
I
think
in
order
to
get
the
same
semantics,
because
it's
an
and
in
the
filters
you
have
to
do
two
different
subscriptions
one
asking
for
a
type
of
issue
and
then
another
asking
for
a
type
of
push.
But
basically
everything
else
is
the
exact
same
okay,
that's
that's
the
way
it
would
have
to
be
today,
based
between
our
spec
and
the
way.
Github
works,
okay
and
notice
that
you
know
this
is
asking
for
the
generic
issue
thing
we
just
like
above.
A
A
A
Maybe
ask
this
later
on,
but
I'm
asking
now
anyway,
is
this
okay
right,
because
in
this
in
this
simple
case,
it's
easy
to
say
well
dummy
you
should
have
used
the
type
field.
That's
what
the
you
know
that
gives
you
the
or
semantics,
but
you
know
what,
if
I
wanted
to
use
prefix
here
instead
and
allow
a
little
bit
of
wild
carding
that
pushes
me
towards
two
different
subscribes.
So
my
question
for
the
group
is:
should
filters
allow
for
or
semantics
in
some
way?
E
L
E
H
A
A
A
H
H
We
only
have
one
filter
to
play
with,
so
we
said
okay,
but
we
want
to
have
combinations
of
those.
So
you
make
the
filter
that
is
actually
a
list,
and
then
the
filter
has
inherent
has
an
inherent
semantic
that
is
all
in
any
or
not,
and
then
you
can
stuff
alter
other
filters
in
there,
but
effectively.
H
A
Right
and
so
let
me
echo
that
back,
it
sounds
like
what
you're
saying
is.
If
we
were
to
match
amqp,
we
would
remove
the
array
from
here
and
it
would
just
be
a
single
thingy,
but
in
order
to
get
the
multiple,
even
the
and
that
we
have
today,
you
would
have
to
start
out
with
a
grouping
dialect
and
under
there
use
an
all
right
and
then
list
out.
In
essence,
this
thing,
as
well
as
one
of
the
choices
there.
H
H
H
So
if
you,
if
you,
if
you
look
at
json,
schema
for
how
you
define
a
type
and
what's
permitted
in
there,
you
have
a
choice
of
one
off
or
all
off
and
any
off
which
basically
gives
you
like
duct
type
options
for
how
the
type
might
look
like.
So
that's
that
it's
kind
of
similar,
so
it's
also
they're,
not
choosing
ends
and
or
in
those
constructs,
but
they
have
these
all
in
any
and
then
one
option
and
one
is
effectively
just
all
with
one
one
inside
of
it.
A
A
I
I
like,
if
we
I
do,
think
we
need
some
sign
up
or
mechanism
personally
and
I
think
a
grouping
dialect
makes
a
lot
of
sense
to
me
and
if
we
introduce
that,
I
then
like
the
idea
of
moving
the
array,
because
I
don't
like
treating
and
as
special
right.
So
I
like
I
like
the
direction
you
guys
took
with
all
that.
So
this
has
a
lot
of
appeal
to
me
at
least
initially,
so
I
like
it
as
well
ryan.
Did
you
want
to
chime
in
here
yeah
I'll,
speak.
P
A
All
right
cool,
thank
you
for
speaking
up.
Anybody
else
want
to
chime
in
all
right,
in
that
case,
not
hearing
any
objection.
Let's
work
with
that
as
a
decision
and
see
how
that
looks.
So
let
me
just
go
up
here,
whoop,
what
the
heck
did.
I
do
eh
I'll
work
on
adding
to
the
list
up
top
of
what
we
agreed
to
later.
A
A
C
H
H
H
H
A
I
know
yeah,
I'm
leaning
a
little
bit
more
towards.
I
want
to
understand
the
use
case
better
because
filtering
down
to
just
one
exactly
one
event
type
and
trying
to
understand
why
you'd
need
that
as
a
filter,
but
I
also
I'm
okay
with
adding
it.
If
people
think
it
may
be
useful,
we
could
always
remove
it
later,
but.
A
P
C
A
H
A
A
Okay,
cool.
Thank
you
all
right,
moving
forward,
then
just
for
fun,
I
decided
to
see
what
it
would
look
like
if
we
actually
use
the
mythical
sql
dialect
that
we've
been
talking
about
and
it
seemed
fairly
straightforward.
Obviously
this
would
need
to
be
com,
github,
dot,
issue
and
github.push,
but
it
seemed
like
it
was
fairly
straightforward
to
do.
Does
this
look
like
I'm
sorry,
go
ahead.
H
Yeah,
so
this
sorry
to
answer
your
question:
does
this
look
like?
Yes?
Does
it
look
like
right,
but
I
have
something
I
have
something
else
that
I'm
gonna
and
you
are
typing,
so
I
would
like
to
try
something
something
else,
and
that
is
the
instead
of
formulating
the
filter
like
like
you
do
now,
we
could,
and
that
is
like
the
filter
object
inside
the
filter.
Object,
have
the
the
filter
type
be
the
key
of
an
of
the
object
that
then
describes
the
the
details.
O
N
A
Well,
well,
cummins
is
bringing
it
up.
Lou
you're,
I
don't
know
the
answer
to
that
question.
We
I
think
we
may
still
need
the
sql
dialect
just
because
some
people
may
want
to
use
an
sql
processor
that
they
already
have
in
their
back-end
system,
because
that
makes
it
really
really
easy
for
them.
So,
for
example,
I
can
imagine
somebody's
saying
you
know
what
I'm
not
going
to
support
this
grouping
dialect.
A
That
clemens
came
up
with
I'm
going
to
just
use
a
sql
query,
because
all
my
events
are
in
a
database
and
I
could
just
slap
in
this
expression
to
my
current
sql
engine
and
it
just
works
so
like
I
could
imagine
when
I
want
to
get
rid
of
it.
Like
imagine,
people
choosing
one
or
the
other,
but
that's
just
me
anonymous.
H
N
H
H
H
Where
you
basically
get
basically
make
the
filter,
so
the
filter
needs
to
live
inside
of
an
object,
because
otherwise
the
key
would
not
be
unique,
but
it
can
then
effectively
once
you
have
the
key,
then
you
know
what's
following
so
r
is
always
an
object
and
n
is
always
an
object
and
not
is
probably
also
sorry
all.
Are
they
always
arrays
and
not
is
also
an
array?
H
H
H
C
I
C
I
H
A
Well,
we
can
so.
Let
me
ask,
let
me
ask
this
while
we're
while
we're
thinking
about
this.
So
what
do
people
think
is
this
stuff
in
pink
or
whatever
color?
That
is.
Is
this
a
direction
people
would
like
to
consider.
I'm
not
saying
definitely
go
with
it,
but
if
we
think
it's
an
interesting
option
after
today's
phone
call-
and
I
write
up
again
what
we've
agreed
to,
I
can
list
this,
as
you
know,
another
alternative
to
this,
a
little
more
verbose,
syntax
that
people
can
see
it
in
action
and
and
play
with
it.
A
N
S
H
Jason
schema
itself
uses
that
so
I
think
as
I
just
as
I
just
just
there,
there
we
go
so
jason
schema
is
using
that
construct
and
I
don't
think
that
you
can
describe
json
schema
and
json
schema,
which
means,
but
don't
ask
me
how
I
do
this,
I'm
just
assuming
that
you
can.
So
that's
that's
what
I'm
that's
the
inspiration
for
what
I
just
what
I
just
said.
A
H
H
H
Yeah
because
I
have
to
I
have
to
I
have
to
with
the
open
api
anyways,
because
I'm
I'm
literally
coding
to
it
now
right
now
to
for
the
for
our
interrupt
effort,
and
so
therefore
I
and
our
our
our
open
api
spec
in
the
repos
is
outdated.
So
I
have
to
go
and
update
that,
so
I
would
go
and
make
a
make
and
make
a
version
that
that
uses
that
all
right
cool,
so
I'm
gonna,
I'm
gonna.
So
let
me
let
me
make
that
concrete.
A
A
A
All
right:
okay,
let's
go
back
okay,
so
this
is
actually
a
good
stopping
point.
Yeah
I
had
to
have
more
in
the
dock,
but
since
it's
time
for
a
regular
phone
call,
let's
go
back
over
to
here
and
christoph.
I
got
you.
Thank
you
just
roll
call.
Before
we
go
back
to
the
other
things.
Let's
see,
andreas
no
andreas
dropped,
gail!
No
john
laswell!
You
there
yep
all
right
lucas,
frank
yep!
Here
all
right
christopher!
I.
P
E
D
A
A
A
A
Yeah
well
yeah,
because
the
because
we're
gonna,
obviously
we
get
oh,
I
need
actually
I'm
pretty
sure
we
get
two
one
for
cloud
events
and
one
for
serverless
working
group.
Assuming
we
do
get
two
you
and
I
talked
offline
about
making
the
serverless
workflow
take
over
the
serverless
working
group
session
and
whether.
A
A
I
A
All
right,
thank
you.
Moving
forward
a
couple
of
pr's,
so
this
one
we
skipped
last
week
because
I
thought
the
person
I
was
chatting
with
may
want
to
chime
back
in,
but
he
didn't
so.
I
think
this
one's
ready
to
go
this
basically
just
talks
about.
Oh,
we
never
did
mercy.
Okay,
yeah.
This
basically
talks
about
hold
on
a
minute.
A
Okay,
I'm
sorry
that's
getting
confused.
This
is
about
dealing
with
errors,
and
basically
this
is
just
saying
in
the
primer
that
errors
are
just
like
any
other
cloud
event
and
that's
about.
As
far
as
we
go
I'll,
let
you
guys
read
it
in
case
you
having
a
chance,
give
me
a
second
there.
While
I
take
care
of
something
in
the
background
here,.
A
All
right
and
then
down
here
it
was
just
syntactical
cleanup
more
than
anything
else
again,
this
is
in
the
primer,
so
it's
not
normative
any
questions
or
comments.
Concerns
about
this
text.
Oh,
I
did
also
add-
I
think,
two
weeks
ago,
this
second
paragraph
based
on
that
person's
question
about
the
adapters
and
stuff
and
how
they
relate
to
all
this.
A
All
right
next
technically,
this
was
open
today
and
I'll
if
we
like
it
I'll
wait
until
the
end
of
the
week
to
merge
it.
But
last
time
we
talked
about
I'm
sorry
during
the
last
design
session,
somebody
it
may
have
been
classic.
I
remember
noticed
that
source
template
was
missing
in
the
discovery
spec
in
the
pseudo-schema
section.
So
this
is
just
an
example
of
you
know
in
suicide.
What
the
subscribe
looks
like
what
the
discovery
looks
like
our
discovery
service
looks
like
so
I
just
added
it
in
there.
A
E
A
Of
the
definition,
so
I
just
want
them
to
be
the
same,
and
then
I
just
remove
some
tabs
here.
So
really,
this
is
the
only
real
change.
That's
not
sync
tactical!
I
just
added
this
to
the
pseudo
schema,
any
objection
with
that
and
if
everybody's
okay,
with
it
I'll,
wait
until
the
end
of
the
week
to
merge
it
and
I'll,
let
people
know
they
have
that
much
time
to
review
it.
But
it's
just
a
syntactical
thing.
A
A
A
A
Okay,
so,
but
please
everybody
when
you
get
a
chance
to
review
that
all
right
now.
What
I
wanted
to
do,
I'm
sorry.
Are
there
other
pr's
that
need
addressing?
I
believe
these
four
down
here
are
still
waiting
for
updates.
I
did
not
notice
any
updates
go
through
and
I
can't
remember
for
sure
who
owns
them
other
than
I
know
for
a
fact.
A
Clemens
at
least
owns
one
lance
owns
one
and
then
clemens.
You
have
a
to
do
on
one
that
you
don't
own,
but
you
promised
some
some
updates
or
proposal
related
to
it.
I
can't
remember
who
else
is
involved.
I
know
at
least
you
two
are
involved
so
you're
being
nagged.
Sorry,
yes,
okay,
nag,
taken
excellent,
okay!
A
A
U
A
All
right,
thank
you,
scott
appreciate
that
all
right
this
one,
so
this
person
is
complaining,
saying
geez,
it's
annoying
that
we
don't
allow
dashes
and
I
think
he
actually
talks
about,
underscores
too
yeah
in
our
attribute
names
and
he
would
he
wants
to
know
if
we
can
extend
it
I'll.
Let
you
guys
actually
read
this.
A
A
T
B
H
U
R
U
H
So
dashes
are
a
problem
because
dashes
are
not
allowed
in
language
mappings,
so
they
cause
problems,
so
they
turn
into
something
else,
sometimes
the
underscore
character
which
is
different
and
then
they
become
confusing.
Because
then
you
know,
what
are
you
going
to
do
with
the
underscore
character?
Does
it
say
an
underscore
character,
or
does
it
become
a
dash
and
then
underscore
is
not
allowed?
H
E
H
H
A
A
A
A
H
N
A
A
Oh
yeah,
okay,
yeah,
so
this
person
initially
said
hey.
Why
don't
we
add
a
correlation
id
basically,
and
I
tried
to
explain
that
we've
been
down
this
path
before
we
couldn't
come
up
with
a
single
definition
that
satisfied
at
least
the
majority
of
the
use
cases,
and
since
we
couldn't
get
agreement
on
what
a
single
definition
should
be,
we
decided
to
punt
on
it,
and
people
can
always
add
extensions
for
it.
A
However,
he
does
specifically
microsoft
azure
and
he
does
talk
about
it
being
you
know,
picking
up
their
definition
and
saying
oh
they're,
all
related
to
the
same
uber
operation
and
just
last
night
I
responded
saying:
well
that's
great,
but
that's
just
one
definition,
because
other
people
look
at
it
as
potentially
a
parent-child
relationship,
not
just
part
not
just
related
to
the
same
uber
thing,
and
that's
exactly
why
we
decided
to
punt
on
this.
So
I'm
inclined
to
say
we
should
keep
this
one
closed
as
well.
T
I
hope
I'm
gonna
say
I'm
not
gonna,
say
something
stupid,
but
correlation
id
to
me
sounds
I
mean
we
have
the
partition.
Key
partition
key
is
somehow
I
mean
the
key
of
a
message
in
systems
that
their
partitions
and
stuff
like
that
are
are
somehow
semantically
related
to
like
a
to
something
like
a
correlation
id.
T
A
A
T
T
O
H
H
A
H
B
A
Look
we
we're
not
changing
our
mind,
at
least
as
of
right
now,
however,
if
this
person
feels
strongly
about
it,
just
like
anybody
else
he's
welcome
to
open
up
a
pr
to
create
it
as
an
extension,
and
if,
for
some
reason
that
extension
becomes
very,
very
popular,
then
we
consider
consider
adding
it.
We
can
consider
adding
it
to
the
spec,
but
as
of
right
now
we
have
no
desire
to
try
to
come
up
with
a
single
definition.
We've
failed
in
the
past.
A
E
A
A
A
A
God
you're
right,
I
free
out
of
you.
Yes,
thank
you
very
much
all
right.
Anybody
else,
all
right
in
that
case,
if
you
do
not
care
about
the
deep
dive
design
or
you
don't
care
about
the
discovery
interop,
you
are
free
to
go
and
thank
you
all
for
joining.
Otherwise
we're
going
to
switch
back
to
the
deep
dive
design
discussion
all
right.
Thank
you.
Everybody
for
joining.
A
A
These
things
are
called
and
there's
an
implicit
and
because
it's
an
array-
and
we
had
some
discussion
and
we
decided
well,
let's
make
it
a
singleton
instead
of
an
array
but,
however,
add
a
grouping
dialect
so
that
you
can
then
add
in
whatever
semantics
you
want,
basically
an
and
or
in
a
not-
and
this
allows
for
nesting
of
these
filters
as
well,
to
give
you
whatever
kind
of
complicated
things
you
want
to
do.
But
that
means
the
bare
minimum
that
people
might
choose
to
support
would
just
be
if
they
just
support
just
basic.
A
It's
no
ans,
no
ors,
just
a
simple
string,
matching
type
thing:
okay,
so
that's
how
we're
going
to
get
ors
into
the
filter.
Expressions
is
through
this
grouping
grouping
dialect
and
then
the
open
question
was
is
okay,
we've
got
an
and
an
or
not
should
we
do
an
exact
one
kind
of
thing
or
one
of
thing,
and
we
decided
as
of
right
now
to
not
include
it,
but
to
revisit
it
later,
people
can
come
up
with
a
with
a
really
good
use
case
for
why
we
want
it.
A
Okay.
The
other
thing
I
want
to
bring
forward
is,
as
we
had
that
discussion
clemens
as
we
got
into
this
sql
example.
Just
because
I
wanted
to
see
what
it
would
look
like
if
we
actually
use
the
mythical
sql
proposal
that
slinky
was
working
on
and
what
it
would
look
like
and
it
you
know
it's
a
fairly
nice
compact
thing,
pretty
cool.
A
A
Filters
right
now
are
basically
defined
as
conceptually
filtering
over
a
stream
of
events
that
are
coming
from
the
event
producer
right.
It's
that
phase
two
that
we
talked
about
where
phase
one
is
creating
the
event
phase
two
is
filtering
the
events
and
then
phase
three
sending
so
phase
two
as
we
currently
have
it.
Sort
of
as
a
mental
model
is
strictly
filtering
over
this
stream,
which
means
you're.
You
can
only
filter
on
the
properties
that
appear
in
each
event
as
it's
going
to
appear
on
the
wire
okay.
A
So
I
started
wondering
especially
during
the
previous
incantation
of
this
github
example
of
well
what
if
I
don't
want
to
filter
on
something
that
appears
in
the
wire?
What
if
I
want
to
filter
on
some
attribute,
that's
known
to
the
event
producer,
but
it's
not
actually
manifested
on
the
wire
itself,
should
filters
be
allowed
to
actually
include
things
that
are
not
in
the
event
itself?
A
A
If
someone
wants
to
support
filtering
over
something,
that's
not
on
the
wire,
I
would
be
inclined
to
say
fine.
You
can
do
that,
but
use
the
config
stuff
that
we
talked
about
and
define
your
own
config
property
thingy.
Even
if
that
config
property
thingy
is
a
filter,
do
your
own
thing,
but
let's
keep
filters
pretty
pure
and
simple,
and
it
impacts
just
what
goes
on
the
wire.
But
that
was
just
my
initial
thought
process.
A
C
A
Right,
okay,
cool
all
right.
I
just
wanted
to
make
sure
we
thought
about
that.
Okay,
so
this
isn't
actually
trying
to
get
to
any
kind
of
decision
other
than
as
I
was
thinking
about
this
last
night,
I
thought
well
what
happens
if
someone
actually
doesn't
want
to
specify
source
or
type,
and
they
want
to
try
to
specify
the
entire
github
subscription
that
we've
been
playing
with
using
just
filters.
A
Okay,
and
what
I
decided
to
do
is
say:
okay.
Well,
what?
If
I
choose
to
write
it
as
well?
Here's
my
normal
filter.
I
want
just
these
two
types
of
events,
but
instead
of
specifying
the
event
source,
I'm
going
to
specify
it
where
there's
a
property
called
owner
and
repo.
Actually
this
isn't
going
to
work
because
we
just
agree.
We
can't
filter
on
things
outside
the
message,
if
you
could
specify
if
you
could
filter
on
things
outside
the
messes.
A
A
A
A
Well,
how
do
you
know
which
event
is
related
to
which
subscription,
and
I
was
wondering
whether
we
should
consider
adding
a
formal
cloud
event
extension,
meaning
it's
an
extension
not
in
the
spec
called
subscription
id
that
way,
people
when
they
get
an
event
can
know
which
description
it's
related
to
so
they
know
exactly
which
subscription
resource
they
need
to
to
delete
to
kill
it
and
that
we
would.
If
we
did
this,
I
would
say
that
we
should
make
it
a
a
should
for
the
subscription
manager
to
include
it
in
the
event
sent.
A
C
I
have
an
opinion
about
this,
so
if
my
subscription
manager
was
acting
as
a
third-party
subscription
facilitator-
and
I
have
producers
not
knowing
about
the
subscription
handling,
it's
gonna
be
tough,
especially
if
I
have
multiple
subscriptions
onto
which
I
want
the
then
producer
or
broker
at
the
subscription
id,
which
is
a
feature
I
wouldn't
have
with
the
remember.
When
we
talked
about
the
firehose
thing,
adding
subscription
ids
to
all
of
the
events,
I
I
don't
think
that
is
a
good
idea.
A
A
C
C
A
H
That's
that's
also
why
it
makes
makes
sense
to
do
it
as
as
a
as
a
as
an
extension,
because
you
can
imagine
that
if
the
subscription
is
is
selecting
the
event
to
deliver
it,
it
could
go
and
annotate
the
events
while
delivering
it.
But
then,
if
you
have
cascades
of
subscriptions,
the
original
subscription
would
be
lost.
H
O
H
Said
it
in
the
first
in
the
in
the
first
hour
with
you,
know
the
bulk
subscription
and
the
sap
thing,
and
then
that
running
through
the
the
the
event
grid
on
our
end
to
kind
of
allow
more
differentiated
subscriptions
will
be
one
of
those
examples
where
you
have
effective
cascading
subscriptions
on
top
of
each
other.
Interesting
would
would
you
and
just
to
add
that
the
the
original
subscription,
the
bulk
subscription
that
that
azure
makes
on
the
sap
system
is
nobody's
business.
H
The
middleware
would
probably
want
to
drop
it
okay
and
then,
and
then
it
might
go
and
add
in
the
end,
I
I'm
not
so
I'm
I'm
I'm
I'm
on
the.
This
is
probably
not
worth
it
side
of
the
fence,
probably
because
it's
adding
complication,
okay.
Well,
I
I
do
appreciate
the
oh,
my
god.
Please
unsubscribe
me
from
this
list
attitude
that
you
have
on
this
one.
A
H
A
So
I
granted,
I
agree
with
you.
It's
not
100
guarantee!
That's
why
I
at
one
point
I
thought
about
even
creating
a
url
to
the
subscription
object
itself,
but
even
that's
not
necessarily
valid,
because
it
could
be.
You
know
a
url
that
the
user
may
not
be
able
to
have
access
to
or
the
url
that
they're
using
doesn't
match
the
url
that
the
system
thinks
is.
People
are
using
right
because
there's
a
some
dns
magic
going
on
right.
That
kind
of
stuff.
That's
why
I
thought
this.
H
That
is
an
annotation
of
the
event,
which
means
this
is
always
applied
by
the
event
the
dispatcher
effectively
that
so
so
the
one
that's
actually
that's
actually
in
the
subscription
that
will
go
and
take
an
event
and
stamp
it
with
its
own
identifier.
When
it
go
when
the
event
is
being
delivered,
then
that
works.
A
Okay,
so
you
said
something
also
in
there
in
a
couple
minutes
ago.
Come
up
previous
minutes.
You
said
something
about
how
making
it
an
extension,
and
that
definitely
was
my
intention.
It
was
not.
I
was
not
planning
on
adding
it
to
any
of
our
specs.
It
was
just
to
be
able
to
think
it's
useful,
but
I
before
I
actually
go
off
and
even
think
about
creating
an
extension
spec.
B
P
I'm
I'm,
I
think,
I'm
a
little
bit
unclear
on
what
is
the
concrete
purpose
of
x.
I
think
we're
like
talking
about
a
few
things
we're
talking
about
being
able
to
unsubscribe,
which
in
that
case
I
would
argue,
the
consumer
should
just
use
the
subscription
id
of
the
manager
that
it
used
to
create
the
subscription
and
shouldn't
know
about
sort
of
the
transitive
chain
of
proxies
and
managers
upstream,
but
we
also
talked
about
being
able
to
disambiguate
duplicate
events
and
also
talked
about
correlation.
A
J
Yeah,
so
I
guess
I
I
had
the
sort
of
the
same,
the
same
question
about
the
the
specifics
of
the
use
case,
but
but
also
adding
the
the
perspective
of
what
additional
burden
are.
We
then
putting
on
each
of
these
subscription
managers
in
terms
of
you
know,
tracking
state
about
these
subscriptions,
especially
as
you
were
just
talking
about
you
know
with
overlaps,
and
you
know
aggregate
proxy
situations
where
they
have
a
fire
hose
and
they're
trying
to
pass
that
stuff
through
as
as
cheaply
and
quickly
as
possible
right.
Are
they
like?
J
What's
the
what's
the
what's,
the
memory
and
processing
burden
that
they're
going
to
have
to
add
on
top
to
be
able
to
support
this
and
then
we're
talking
about
use
cases
that
it's
going
to
be
hard
to
even
support
and
ambiguity,
and
things
like
that
so
yeah.
I
want
to
understand
more
about
specific
use
cases
where
we
think
it's
the
only
way
or
the
best
way
or
somehow
more
efficient,
to
put
that
burden
on
the
on
those
aggregators.
Those
proxies
versus
the
subscriber
having
to
deal
with
their
own
subscriptions.
Q
Yeah,
I'm
also
not
sure
on
on
the
use
case
and
I
think
the
whole
idea
that
you
just
okay-
I
don't
want
to
see
when
I'm
just
unsubscribing,
if
you're
not
so
sure
what
your
subscription
do
in
the
first
place,
then
you
may
delete
a
subscription
that
actually
sends
you.
I
don't
know
five
or
ten
different
event
types
you're,
not
interested
in
this
one
particular
event,
but
then
you're
dropping
all
of
those
event
types.
Q
A
A
E
H
H
Is
it
more?
Oh,
this
isn't
it.
You
know,
there's
a
there's
a.
I
have
a
section
on
this
on
subscription
and
effectively
effectively
describing
the
inherent
mechanisms
of
some
of
the
yeah.
So
there's
exactly
so,
there's
this
consumer
solicitor
delivery,
the
pull
style
and
then
there's
the
push
style.
The
push,
push-style
delivery
and
I
think
those
are
different
in
terms
of
how
we
think
about
those
hdp
doesn't
have
a
mechanic.
H
It
doesn't
so
this
might
get
long
hang
on,
because
I
want
to
say
this
now
in
my
own
words
other
than
just
having
you
read
it,
so
I'm
not
going
to
look
at
it.
There
is.
There
is
there's
one
way:
we
when
you
walk
up
to
a
subscription
manager
and
say
hey,
please
give
me
events,
here's
an
end
point,
that's
what
we
discussed
so
far
and
and
all
the
things
that
you
have
in
your
examples
are
true
for
all
of
the
different
channels:
http
and
mqtt,
and
kafka
and
amkp.
H
If
the
delivery
is
push
meaning,
if
the
delivery
is
initiated
by
the
subscription
manager
or
the
delivery
agent
of
the
subscription
manager,
meaning
the
delivery
manager
actively
opens
up
a
connection
and
then
starts
pushing
events
through
that.
That's
that's
push
delivery.
The
subscription
manager
initiates
the
the
delivery
that
is
suitable
for
all
the
scenarios
where
you
have
serverless.
H
We
still
are
here
scale
to
zero
scenarios,
where
the
resource
is
dormant,
there's
only
some
endpoint,
which
is
listening,
and
then
you
open
up
a
connection
into
that
endpoint.
You
start
pushing
events
to
it
and
then
the
machinery
on
the
other
side
wakes
up
loads,
the
required
code,
and
then
this
dispatches
that
event.
That's
that's
why
push
delivery
is
so
attractive
for
for
serverless.
H
It
also
allows
you
to
go
and
do
you
know
classic
hdp
style,
traffic,
balancing
load
balancing,
because
you
can
basically
just
go
meter
the
number
of
requests
that
you're
getting
and
then
start
start
up
new
new
resources.
So
push
delivery
is
great.
For
that
pull
delivery
is
more
what
you
do
in
classic
messaging
system,
where
you
are
effectively
hanging
on
a
queue
or
you're
hanging
on
a
kafka
topic,
and
you
continuously
start
pulling
events
out
for
that
mechanism.
We
don't
have
to
go
and
invent
anything.
H
The
events
that
you
that
you
want
will
come
out
and
then
the
question
is
there:
how
do
we?
How
do
we
map
some
of
the
constructs
that
we
have
here,
like
our
filtering
capabilities,
etc?
How
do
we
map
those
onto
mqtt
and
there
will
be
constraint
naturally
by
the
capabilities
of
mqtt,
because
you're
choosing
the
pro
the
protocol,
and
so
you
have
a
constrained
set
of
of
ways
and
one
way
or
the
other
what
you're?
H
Choosing
of
what
the
broker
already
gives
you
in
in
amqp,
that's
the
same
thing
you
create
a
you,
create
a
node.
The
node
has
a
distribution
policy
of
copy
that
is
equivalent
to
a
topic
in
mqtt,
and
you
open
the
link
into
it
and
then
messages
flow
out
in
kafka.
You
create
a
consumer
group,
implicitly
you
attach
to
the
consumer
group,
and
once
you
have
a
consumer
group,
you
get
effectively
a
a
copy
of
your
own
stream
or
your
own
copy
of
the
stream,
where
you
can
then
make
progress
on
that
stream.
H
A
H
H
A
H
I
I
I
specifically
made
this
the
sentence
above
the
amputee
says:
it's
non-normative,
I'm
basically
just
mentioning
those
because,
because
it's
I
think
it's
not
up
to
us
to
go
and
you
know
config
define
what
a
broker,
what
a
broker
should
look
like,
and
I
think
it's
not
up
to
us
and
also
not
in
our
powers,
really
to
go
and
say
kafka
should
go
in
and
deal
with
pop
sub
in
the
following
way.
Just
because
the
events
are
cloud,
events
or
or
mqp
or
mqtt
should
do
it
in
this
particular
way.
H
R
Yeah,
so
in
general,
I
completely
agree
to
clements.
We
just
have
some
edge
case
and
might
be
out
of
scope
for
the
specification
here,
but
in
some
cases
you
might
still
want
to
have
this
subscription
api
based
on
cloud
events,
because
the
the
other
end
is,
in
addition
to
just
I
mean,
is
creating
actually
some
endpoint,
for
example,
for
amqp,
let's
say
a
queue
and
and
configuring
this.
So
you
would
then,
as
a
result
of
this
subscription
api
call
get
something
like
a
queue
configured
and
then
do
again
the
pull
style.
Consumption
on
that.
H
A
H
C
It
sounded
as
if
the
subscription
creates
some
sort
of
a
cue
for
the
subscriber
to
consume
from-
and
this
is,
I
think,
a
misunderstanding,
because
even
though
it
is
called
the
pull
style
protocol
model
and
the
the
delivery
of
these
brokers
is
pull
style
to
consumers,
always
because
consumer.
Of
course
it
connects
to
the
broker
and
then
pulls
messages
out
of
it,
but
as
clemens
described
it.
H
Yeah,
you
are
absolutely
correct.
There
are
two
things
here
so
so
the
example
that
that
is
here
that
we're
looking
at
is
wrong,
because
we
will
be
only
configuring
to
send
to
a
so.
This
would
be
effectively
setting
up
a
push
delivery
into
a
kafka.
That's
what
we
would
set
up
with
it
with
an
http
call.
H
A
So
wait:
okay,
wait.
Wait,
wait!
Wait!
Just
let
you
know.
First
of
all,
I
don't
doubt
everything
I
have
here
is
wrong.
However,
keep
in
mind
this
was
not
written
with
I.
This
was
written
with
k
native
in
mind
in
the
sense
that,
if,
if
I
wanted
to
subscribe
to,
in
essence
a
k-native
or
I
want
to
create
a
k-native
event
source
which
that
event
source
is
going
to
be
the
one
that's
going
to
be
pulling
from
kafka,
but
then
delivering
things
to
me
over
http.
A
H
Okay,
great
so,
okay,
so,
okay,
I
understand
that
now
that
makes
that
makes
a
little
confusing,
but
I
understand
that
now
yes,
yeah
yeah,
you're
you're
you're,
now
throwing
in
some
some
some
overlapping
concepts,
because
this
is
what
you
have
in
config
here
is
completely
a
concern
of
k-native
and
something
that
nobody.
This
is
an
internal
implementation
detail.
Q
A
World
today,
when
I
say
hey,
I
want
to
get
events
from
kafka.
I
set
up
an
event
source
and
I
can
I
basically
give
it
this
information
yeah,
okay,
but
then
I
have
to
tell
it
where
to
send
it
to,
and
that's
what
does
here.
So
this
is
the
exact
equivalent
of
a
native
event
source.
I
just
put
it
into
our
syntax.
H
Okay,
okay,
so
that
then
the
number
said
that
yes,
so
that
was
the
so
so
if
you
were
just
if,
if
there
are,
if
you're,
using
kafka
as
your
pop-up
engine
and
and
what
we
do
with
the
subscriptions
api
is
we
want
to.
We
want
to
facilitate
subscription
management
effectively
right
for
in
an
upper
interoperable
fashion,
and
if
your
subscription
engine
is
an
nqp
broker
or
an
mpt
broker
or
kafka,
then
well,
you
have
a
subscription.
H
You
have
a
you,
have
a
pop-up
engine
right
there
and
if
you,
if
you
are
building
this
with
rest
htp
as
we're
doing
here,
then
we
need
to
go
and
effectively
add
the
the
the
pops
up
engine.
If
you
will
to
as
a
as
a
thing
and
we
need
to
make
sure
that
the
the
pops
up
engine
is
interoperable.
That's
what
we're
doing
here.
So
that's
the
the,
but
we
don't
need
to
do
this
for
for
for
pops
up
engines
which
people
already
have.
H
That's
something
that
is
that
you
do
implicitly
in
mqtt
and
that
you
might
also
do
in
mqp
is
that
if
you
allow
dynamic
entities,
then
you
can
go
deliver
into
something
that
doesn't
exist
and
then
the
the
queue
or
the
topic
will
then
come
into
being
so
so.
Yes,
the
the
subscription
can
cause
a
cue
to
appear
that
hasn't
appeared
yet,
but
the
broker
obviously
need
to
exist.
A
A
The
fact
that
we
even
talk
about
mqtt
and
nats
and
other
stuff
is
interesting,
but
it
really
has
no
effect
on
the
spec
itself
right,
because
I
think
what
you're
basically
saying
is
our
spec
is
all
about
push
style
delivery,
because
any
kind
of
pull
style
delivery.
Well,
they
already
have
it
defined.
We
don't
need
to
touch
it.
H
Yeah
the
reason.
The
reason
I
put
that
in
here
is
that
I
know
how
this
goes
and
and
people
will
say
now.
I
have
to
go
and
build
all
this
complicated
around
my
my
kafka
broker
to
be
compliant
with
cloud
events,
so
so
I
want
I
want.
I
want
to
make
make
it
clear
that
our
intent
that
the
intent
of
this
group
is
no?
H
No,
no
don't
do
this,
use
the
kafka
mechanisms
they're
fine-
and
this
is
that
that's
that
this
is
effectively
in
the
smack
in
the
middle
of
the
spec,
a
a
clear
hint
that
you
don't
have
to
go
and
construct
any
of
that
stuff.
If
you
already
have
have
a
pop
up
engine
and
if
you're
fine
with
using
mqtt,
npp
and
kafka
protocols,
if
you
want,
if,
if
your
world
is
http
rest
and
that's
all
you
do
and
you're
and
you're
living
in
rpc
world.
Well,
then
you
have
problems
with
directionality.
H
That's
that's
the
motivation
for
having
that
here,
because
because
I
can
bet
that,
if
we
don't
include
this,
if
we
don't
make
that
clear
that
all
all
kinds
of
folks
are
going
to
build
weird
contraptions
around
these
brokers
just
to
be
compliant
with
cloud
events
and
that's
what
I
want
to
avoid.
Okay,.
A
H
A
Q
I
don't
necessarily
have
an
opinion,
but
I
have
a
question
for
clements,
so
so
for
our
company.
What
we
sometimes
want
to
do
is
build
integrations
that
are
basically
event:
consumers,
they're
open
source,
so
people
should
install
them
in
their
own
system,
run
them
maybe
modify
them
to
make
fit
for
their
use
case
and
then,
depending
on
who
the
customer
is,
they
usually
have
their
thing
set
up,
so
they
may
have
kafka.
Q
They
may
use
something
from
the
cloud
provider
so
that
they're
kind
of
set
up
already.
So
we
think
cloud
events
would
come
in
there
really
well
to
yeah
abstract
over
those
layers
for
us
so,
but
in
that
case
also
part
of
this
is
that
we
know
what
to
subscribe
to.
So
that
would
always
be
the
same.
So
if
we
had
so
basically
what
I'm
saying
all
this,
what
do
you
label
all
the
around
kafka
and
so
on?
That's
actually
what
would
be
useful
for
this
case
yeah?
What
I
hear
you.
H
H
Q
E
Q
H
But
for
that
case,
but
I
mean
if
a
com,
if
you
have
a
customer
who
says
okay,
we're
doing
everything
in
kafka,
you're,
okay,
because
you
have
a
common
way
of
how
how
to
express
events,
and
then
you
only
have
one
api
and
one
mechanism
for
how
you
get
those
events,
and
that
is
kafka
and
and
with
this
document
as
it
stands,
you'll
be
okay
with
cloud
events,
because
we
say
kafka
is
a
fine
way
to
go
and
deliver
cloud
events.
You'll
be
okay,.
Q
H
H
Just
for
our
cue
right,
that's
that's!
That
is
already
really
complicated
and
we
can't
like.
We
can't
agree
on
on
those
things
for
for
something
like
like
kafka,
because
for
kafka,
the
apache
kafka
project
equals
equals
confluent
they're
running
away,
they're
running
ahead
with,
with
whatever
the
kafka
api
is,
and
then
there
is,
you
know,
pulsar
and
there's
azure
event,
hubs
and
there's
kinesis
and
they
all
look
different
and
having
a
common
api
across.
A
Yeah,
so
I
just
realized
that
technically
we're
ten
minutes
over
for
the
discovery
interrupt
call.
So,
let's
just
quickly
does
anybody
have
any
topics
they
want
to
bring
up
for
the
discovery
interop,
I
suspect
everybody
is
either
busy
or
clements
are
still
coding
away,
but
is
there
anything
people
want
to
bring
up.
A
A
A
N
A
C
A
C
I
can
have
this
push
style
delivery
to
my
consumers
and
if
it's
kafka,
then
I
know
it
can
produce
into
my
kafka
cluster,
but
the
configuration
you
gave
here
telling
the
subscription
manager
how
to
obtain
the
events
from
another
source.
That
was
a
bit
baffling
to
me.
So
that's
what
it
was
intended
right.
I
I
overlooked
that
the
protocol
selection
was
http
and
then
it
gave
a
kafka
configuration.
C
A
So
I
I
think
the
way
you
described
it
is
the
way
I
had
in
my
mind
because
to
me
that's
exactly
what
k-native
does
right,
these
little
event,
sources
that
you
can
create
in
k-native
to
me,
they're
like
adapters
right,
it's
saying,
hey,
go
manage
this
event
producer
for
me
or
talking
to
this
event
producer
for
me
and
in
this
particular
case,
the
event
producer
or
that
they've
been
producer.
But
the
thing
where
I'm
going
to
get
the
events
from
is
a
kafka
queue
right,
and
so
this
is.
A
This
is
how
I
want
the
k-native
infrastructure
to
talk
to
kafka
for
me,
but
once
it
gets
those
events,
it's
going
to
send
it
to
me
over
http.
So,
yes,
it
is
like
an
adapter
and
whether
it
makes
sense
or
not
to
set
up
this
adapter
via
a
subscription
thing.
I
don't
know.
I
just
thought
it'd
be
interesting
to
see
what
it
would
look
like
if
you
tried
to
model
it
that
way
and
if
we're
going
to
model
it
that
way,
I
couldn't
think
of
any
other
way
to
specify
this
three
bits
of
information.
C
Up
where
I
did
so
in
a
classical
sense,
it
would
be
a
subscription
to
a
kafka
or
a
sorry
subscription
to
a
subscription
manager
that
can
produce
events
through
a
kafka
and
channel,
and
then
you,
I
would
point
it
to
my
little
events.
Oh
my
k
native,
does
it
come
with
the
broker?
That's
the
question
I
mean
canadians
really
can
only
consume
and
then
give
the
events
deliver.
The
events
as
an
http
push,
but
it's
not
operating
the
kafka
cluster,
isn't
that
right.
A
A
C
H
I
no
there
is
not
because
those
it's
meant
to
be
a
synonym.
It's
we
have
the
reason.
The
reason
why
this,
why
this
a
little
bit
high
nose
term
consumer
solicited
exists,
is
because
we
are
already
had
disputes
about
the
terms,
pull
style
and
bush
style,
and
so
therefore
I
I
use
that
as
a
clarification
term,
that
someone
has
initiated
the
initiating
the
delivery
and
to
make
clear
what
what
pull
and
push
means.
H
H
The
the
the
kafka,
the
kafka
thing
here
in
this
in
this
very
example-
you
should
ignore
this,
because
it
has
nothing
to
do
with
kafka.
It
is
simply
about
how
the
implementation
of
this
particular
subscription
manager
turns
around
on
its
backside
and
goes
and
grabs
events
from
kafka
that
it
will
then
go
and
push
deliver
to
this
http
endpoint
from
a
cloud
events
perspective,
the
config
that
that
that
you
see
here
has
no
function
whatsoever.
This
is
purely
just
to
inform
some
internal
implementation
of
how
to
go
and
get
get
some
events.
A
C
M
C
A
A
The
definition
of
the
config
section,
though,
is
up
to
the
subscription
manager
right
because,
even
in
even
in
our
github
case,
well,
we
don't
have
any
config
anymore
right,
but
let's
say
there
was
a
config
event
in
github
right
in
order
to
understand
that
you
have
to
understand
the
discovery,
entry
for
github
to
know
what
those
config
values
mean
right
because
the
discovery
endpoint.
Let
me
see
if
I
can
find
it
here.
The
discovery
endpoint
gives
you
the
name,
and
it
gives
you
the
type
right,
but
that's
it
to
understand
what
that
actually
means.
A
You
have
to
go
manually.
Go
look
at
the
specification
for
that
field
to
understand.
Oh,
the
word.
Org
means
github
organization
right,
so
it's
not
something
you
can
programmatically
fill
in
right
unless
this,
unless
you
happen
to
know
in
advance.
Oh,
the
url
points
to
this
thing
and
and
therefore
I
know
what
it
means
right,
but
if
it's
a
brand
new
url
yeah
as
a
person
you're
going
to
have
to
go,
read
it
and
go
understand
what
it
means
to
use
this
particular
this
particular
name
inside
config
and
so
whoop.
A
C
A
C
C
Just
this
thing
right
here,
yeah
not
even
shows
the
syntax
highlighting
I'm
seeing
but
okay.
So
I
had
a
look
at
this
flattening
of
the
dialect
and
when
you
compare
the
first
two
in
all
it
to
me,
it
doesn't
really
add
a
lot
sorry
of
clarity
to
the
specification
because
we're
adding
a
nested
object
where
we
had
just
two
parameters
in
parallel
and
then
my
question
following
that
optimization.
I
agree
it
reads
nicely,
so
we
you
can
read,
sql
condition,
type
equals
and
so
on.
C
E
C
Please
go
down
a
bit
if
we
said
okay
basic
is
just
an
indirection
of
specifying
one
of
the
three
matching
types,
exact
prefix
and
suffix.
We
could
flatten
it
even
further
and
say
take
the
property
that
we
want
to
compare
as
the
parameter
name
so
here
type
and
put
the
value
in
the
value
section
of
that.
So
we
can
have
an
exact
matching
on
type
com,
github
issue
or
a
prefix
equivalent
with
com
github
and
the
suffix
equivalent.
A
H
H
Yep,
that's
actually
not
terrible,
that's
that's.
We
have
an
exact
filter
or
prefix
filter
and
suffix
filter
and
a
secret
sql
filter
so
effectively
we're
now
which,
which
mirrors
effectively
the
amkp
model.
Where
you
only
have
you
don't
deal
in
dialects,
but
you're
dealing
individual
filters
and
then
you
can
just
go
and
compose
the
filters.
I'm
fine
with
that.
C
A
A
A
G
Sometimes
some
events
come
through
one
set
of
technologies.
While
another
of
the
events
come
through
another
set
of
technology,
I
don't
know,
I'm
I'm
being
kind
of
hand-wavy,
but
I
think
these
are
the
harder
cases,
something
that,
as
a
user
I
want
to
be
able
to
specify
is
something
like.
I
would
like
the
an
order
guarantee
over
the
events
that
the
order
they
were
that
they
are
recorded
in
the
upstream
sources,
is
the
order
that
I
will
see
them
as
a
downstream
consumer.
A
G
G
The
the
kind
of
considerations
and
concerns
that
are
being
properly
expressed
in
their
that
are
really
the
real
kind
of
expressing
the
real
needs
of
the
subscriber.
I
I
think
that
making
sure
that
those
are
present
present
and
accounted
for
is
is
of
a
higher
priority
than
how
we
factor
it
all
in
there.
F
A
Right
and-
and
I
kind
of
then
took
that
that
thought
process
to
an
extreme
and
basically
said
well,
everything
is
just
a
top-level
thing
right
and
you
just
basically
specify
a
whole
bunch
of
different
properties
just
to
tell
the
the
event
manager
or
the
subscription
manager
what
you
want
to
have
happen
right
and
whether
it's
a
protocol
thing
versus
a
filter
thing
versus
config
thing.
They
don't
know
they
don't
care
it.
Just
you
know,
there's
a
property
to
find
that
you
need
to
fill
in.
A
That
says,
hey
make
this
semantic
happen
right
and
trying
to
categorize
things
was
kind
of
silly.
The
same
way,
we
got
rid
of
buckets
entirely
in
cod
events
right
because
I
argued
it
was
silly
to
try
to
to
define
a
foo
in
one
bucket
to
mean
something
different
to
being
a
different
thing
from
a
foo
in
a
second
bucket
right.
That
was
just
going
to
be
really
confusing.
So
why
not
move
everything
to
top
level
and
just
pick
a
better
name
than
foo?
A
G
I
me
personally,
I
have
some
very
strong
opinions
about
what
I
want
to
be
guaranteed
through
that
entire
delivery
chain.
Now
you
know
my
bias
here
is
I'm
really
kind
of
obsessive
about
order
order
is
equivalent
to
consensus
and
you
can
achieve
it
without
any
consensus,
algorithm
or
coordination.
If
you
can
maintain
order
throughout
the
entire
system
and
where
there
are,
you
know,
uncorrelated
orders,
you
create
a
join
of
event
streams
in
order
to
mainta
to
establish
causal
order
between
events
and
and
therefore
you
know
anyway.
This
is
the
sort
of
stuff.
G
I
I
spend
a
lot
of
brainpower
thinking
about,
because
I
really
like
the
notion
it
ticks
my
brain,
but
that
means
that
I
have
really
strong
opinions
about
what
I
want
from
a
subscription
and
particularly
that
I
wanted
to
maintain.
Give
me
an
order,
guarantee
a
guarantee
that
the
order
originally
observed
will
be
maintained.
G
So
you
know
this
is
why
clemens
I
use
event
hub
and
hate.
What
is
it
the
other
one,
the
the
ones
you
guys
always
a
great
grid?
You
push
a
lot,
or
at
least
the
marketing
pushes
a
lot,
but
I
I
use
that
because
of
this
order
guarantee
and
the
way
that
that
drives,
how
my
systems
behave
and-
and
while
I
can
specify
the
last
hop
cloud,
events
allows
in-
or
at
least
what
I'm
seeing
specified
here
in
the
last
hop
cloud.
G
So
you
know
I'm
being
very
indulgent
here.
The
real
thing
is,
you
know
the
question
was
you
know,
do
you
have
any
of
those
scenarios
here
because
I
think
they'll
be
instructive
for
the
sorts
of
things
as
we
define
cloud
events
and
thought
about
it
and
talked
about
it
in
the
past
that
we
should
probably
bring
to
bear
because
they
really
show
up
in
the
subscription
and
delivery.
A
G
Right
is
it
that
you
think
maybe
this
is
the
question
is
to
say
this.
I
think
this
is
a
really
valuable
exercise
that
these
examples
of
that
caused
us
to
ask
some
important,
concrete
questions
and
bring
some
of
the
fine
distinctions
to
bear,
and
I
I
was
saying
kind
of
yes-
and
I
think
this
kind
of
more
advanced
case
might
be
something
that
needs
to
be
considered.
A
Okay,
yeah-
and
I
think
that
goes
to
what
I
was
asking
earlier,
which
is
hey
guys.
Think
of
other
examples
that
we
want
to
walk
through,
and
I
think
the
ones
that
are
rattling
around
in
your
head
are
great
examples.
So,
if
you
can
write
so
take
take
dig
one
of
the
examples
that
you
were
just
talking
about
right
and
write
that
down
into
a
doc
and
say
this
is
how
you
would
you
would
model
it
right.
A
This
is
what
you
would
expect
your
subscribe
to
look
like
to
get
the
thing
that
you're
just
describing
with
you
know,
guaranteed
order
delivery,
whatever
it
might
be,
and
let's
walk
through
it
and
see
what
falls
out
of
that.
Maybe
it'll
be
a
very
short
discussion,
because
what
you
write
down
is
exactly
the
way
everybody
else
would
have
done
it.
It
makes
perfect
sense
or
we
end
up
in
a
rat
hole.
Discussion
like
we
have
for
the
last
two
weeks
or
three
weeks,
and
we
have
to
make
some
design
change
to
the
spec.
G
A
A
H
So
so
we
have,
I
think
we
have
a
pretty
complicated
scenario
and
we
will
be
happy
to
talk
about
this
with
as
much
detail
as
we
can.
Obviously
there
is
some
there
will
be
some
stuff
behind
the
curtain,
which
is
not
maybe
not
necessarily
all
pretty,
but
but
in
terms
of
how
the
cloud
events
flow
works
and
how
we
are
using
the
specs
to
make
sure
that
we
can
go
and
coordinate
this.
We
are
both
pretty
well
committed
to
make
sure
that
that
all
happens
in
the
standard
way.
H
I
think
we're
both
realistic
about
having
to
cut
some
corners,
given
that
we
have
to
go
and
ship
something
by
whatever
I
think
august,
but
we
will
certainly
be
able
to
go
and
tell
you
some
what
we're
doing
with
the
specs
or,
for
instance,
the
discovery
documents
already
can
tell
you
there
will
be
and
that's
something
we
discussed
yesterday.
My
assumption
is
that
there
will
be
discovery
documents
and
what
I
mean
document.