►
From YouTube: CNCF Serverless WG 2021-01-28
Description
CNCF Serverless WG 2021-01-28
A
B
Forget
half
the
people
here
or
a
good
portion
of
the
people
here
are
east
coast
or
in
lava
martin
and
eu
too.
If
I
understand
it
correctly,
yeah.
A
B
A
A
A
Okay,
so,
while
we're
waiting,
what
I
was
thinking
about
doing
see,
if
you
guys
are
okay
with
this
was
I
was
going
to
jump
right
into
sort
of
the
design
discussions
and
continue
our
chat
on
this
sort
of
walk-through
and
then
at
the
top
of
the
hour.
I
was
then
going
to
return
to
the
normal
agenda
just
to
cover
some
of
the
high
level
things
or
not
get
rid
of
the
things.
A
Normal
governance
types
things
for
those
people
who
could
only
make
the
normal
hour
and
then
go
back
to
the
deep
dive
and
then
at
the
top
of
the
next
hour.
If
we
have
any
sdk
topics,
so
I
think
we
have
at
least
one
we'll
jump
over
to
sdk
and
then
return
back
to
the
date.
Five
that
way,
people
who
can
only
make
the
normal
schedule
calls
won't
feel
like
they
missed
out.
Does
that
seem
fair.
G
A
Oh
there's,
I
believe
lou's
last
name
is
dang
hold
on
a
sec,
hey
lou!
You,
there
yeah,
yes,
okay,
cool!
All
right!
I'm
gonna
go
ahead
and
get
started.
Hopefully
other
people
will
join
as
we
go.
It's
unfortunate,
clemson
isn't
here
yet:
oh
hey
vlad
because
he
had
to
heal
out
to
stay
on
this
one.
A
But
it
seems
to
me
that
there
really
wasn't
any
objection
to
us
supporting
the
what's
the
phrase
we're
using
for
it
the
aggregation
model
and
so
therefore
being
able
to
filter
on
things
like
source,
as
opposed
to
it,
just
being
something
that's
sort
of
outside
the
the
event.
It
sounds
like
that's
something
that
people
did
want
to
do
so.
A
A
C
Okay,
but
I
think
comments
might
say
no.
A
Yeah,
so
I
was
really
hoping
he'd
be
here,
because
I
know
he
had
some
opinions
about
this,
but
okay,
but
for
now
no
one
else
on
the
call
has
any
concerns
with
that
right.
Okay,
okay,
so
then
I
guess
my
overall
question
for
the
group
is,
as
I
was
putting
together
this
example.
A
The
the
biggest
thing
to
me
was
the
fact
that
I
chose
to
make
the
specification
of
these
properties
to
be
configuration
things
as
opposed
to
filters,
and
remember
correctly,
I
did
that
because
I
wanted
an
implementation
of
this
on
github
to
be
as
small
as
possible
and
require
as
little
work
as
possible
and,
as
I
said,
I
didn't
think
that
they
necessarily
use
filters
per
se.
A
A
Okay,
so
in
that
case,
the
the
the
result
of
that
to
me
was
in
the
spec
today
we
actually
don't
allow
the
filter
to
be
optional
in
terms
of
the
subscription
manager,
I
believe,
has
to
support
the
filter
mechanism
and,
in
particular
the
simple
filter,
dialect
or
filter
type,
whatever
it's
called,
but
it
seems
to
me
if
someone
chooses
to
model
things
this
way,
I
don't
think
we
can
force
them
to
support
filters
at
all.
A
In
other
words,
my
my
net
of
this
is,
I
think,
filters
should
be
optional
to
support
and
therefore
I
think
we
need
a
way
to
advertise
in
the
discovery
spec
whether
the
subscription
manager
supports
any
filtering
at
all
and
in
particular
be
able
to
advertise
that
they
don't
the
exact
mechanism
by
which
you
do
that.
I
haven't
decided
yet,
but
I
wanted
to
see
what
you
guys
thought
about
that
decision.
A
I'm
yeah.
That
was
my
point
right.
I
I
think
I
I
was
uncomfortable
with
the
idea
of
forcing
my
implementation
of
the
github
subscription
manager
to
have
to
support
filtering
because
that
that
actually
could
be
a
fair
amount
of
work,
and
I
did
not
want
to
force
people
to
do
that
if
they
didn't
want
to.
C
A
A
A
A
Okay:
okay,
in.
E
A
D
Well,
yeah
go
ahead,
can
we
I'm
still
thinking
and
trying
to
digest,
but
so
we
said
that
source
is
also
just
another
filter.
Is
that
or
can.
A
D
In
general,
I
like
that
idea,
but
I
just
wonder
if
we
make
either
filters
or
config
I
mean
if
we
both
make
both
of
them
more
or
less
optional,
how
in
the
end,
this
would
work.
If
I
have
something
like
an
aggregator
that
passes
on
subscriptions
upstream,
there's
not
much
in
the
in
them
anymore.
That
helps
routing
those
subscriptions
upstream
and
the
values
in
config
are
more
or
less
proprietary.
In
the
end.
A
Yeah
and
I
apologize-
I
did
mention
this-
the
first
time
we
look
at
this
document,
but
I
think
what
it
does
is
it.
It
makes
the
the
metadata
or
the
discovery
spec
information
more
important
than
ever
right,
so
the
users.
A
A
D
It's
just
the
subscription
does
not
contain
now
a
reference
to
a
source
or
a
service
anymore,
but
you
have
the
the
config
values
and
I'm
wondering
if
that's
still
possible,
I
mean
if
that
really
can
then
support
interoperability.
D
D
Okay,
yeah,
exactly
yes!
So
if
now
in
the
subscription,
I
could
have
this
relation
to
a
service
or
resource.
Then
it
would
be
possible
for
a
subscription
manager
to
to
create
that
relation.
But
if
I
don't
have
that-
and
it
contains
these
config
values,
it's
it's
getting
hard.
A
A
I
chose
to
model
the
specification
of
these
properties
as
a
config
thing,
as
opposed
to
a
filter,
and
so
the
question
wasn't
whether
that
was
the
right
model,
but
whether
it's
an
allowable
model
per
the
spec
and
no
one
disagreed
that
it
should
be
allowable
right,
because
someone
may
choose
to
not
really
want
to
support
filters
at
all.
A
A
This
is
legal
for
the
spec,
whether
it's
preferred
or
not
different
discussion,
but
it's
legal
and
the
other
decision
was
that
would
imply
then
that
filtering
support
by
the
subscription
manager
should
be
optional,
because
today
in
the
spec
it
it
doesn't,
come
right
out
and
say
it.
But
I
think
it's
strongly
implied
that
the
substitution
manager
has
to
support
at
least
the
simple
filtering
dialect,
and
we
kind
of
agreed
that
no,
we
should
make
that
optional,
because
filtering
is
could
be
potentially
very
expensive
for
somebody
and
they
may
not
want
to
support
that
any.
H
The
context
for
the
subscription
is
something
that
I'm
that
I
continue
to
be
on
the
fence
on
the
fence,
for
so
that
the
conflict
here
was
for,
in
my
mind,
for
configuring
that
context,
but
not
for
identifying
it,
meaning.
H
A
H
H
In
order
to
give
you
events,
I
think
those
things
are
different,
but
but
I
would
like
for
the
source
that
we
are
encoding
in
events
to
be
somewhat
correlated
in
some
way
to
how
we
subscribe,
because,
ultimately,
we
are
subscribing
to
events
from
the
source
and
expressing
that
through
the
config
seems
a
little
odd.
A
C
C
C
I
was
not
expecting
to
filter
on
that
and
just
say:
okay
like
it's,
because
the
event
type,
I
think,
but
maybe
I'm
wrong.
If
I
remember
correctly,
I
would
have
defined
like
a
push
on
a
repository
like
a
com.github.repository.push
as
even
type
and
if.
H
H
H
That
is
one
type
that
exists
for
all
the
all
the
the
the
the
storage
change
events
in
all
of
azure
and
it's
being
raised
a
million
times
a
second
so
so
to
to
make
sense.
Out
of
that
event,
you
need
to
have
some
scoping
and
the
scoping
is
being
pro
is
being
provided
by
the
source
and
by
the
subject.
H
A
H
So,
just
just
to
make
that
concrete,
and
I'm
going
to
stick
to
that
to
that
to
the
blob
account,
because
the
storage,
the
storage
thing
and
block
credit
is
pretty
clear.
H
You
do
a
you,
do
a
a
subscribe
gesture
and
then
a
parameter
subscribe
gesture
is
the.
I
is
the
the
the
address
of
the
thing
that
you
want
to
subscribe
on,
which
means
that
is
the
the
the
address
of
that
of
that
block
container,
which
is
a
very
long
ui.
H
The
upside
of
the
ladder
approach
is
that
you
can
go
and
generically
have
one
thing:
that's
identifiable
and
has
an
end
point
and
you
talk
to
it
and
then
you
pass
it
as
a
parameter.
The
upside
of
the
first
approach,
which
means
you're
putting
that
endpoint
right
onto
the
object,
is
that
discoverability
is
better
like.
H
If
you
are
looking
at
the
blog
account
and
its
api,
then
putting
a
subscription
endpoint.
There
makes
it
obvious
that
there
is
an
operation
for
how
you
can
get
to
events
from
that
thing
versus
having
a
subscription
manager
that
lives
somewhere
else
where
you
then
have
to
go
and
literally
know
about
the
the
relationship
between
the
two.
That's
the
that's
the
tension
between
those
two
models.
D
Yeah,
so
I
understand
that
example
for
the
blob
store,
but
that's
that's.
I
think
clements
you're
sometimes
also
using
examples
from
iot.
So
how
would
that
work?
If
a
sensor
is
a
source
and
you
have
hundreds
of
them,
you
then
have
to
create
a
subscription
per
sensor.
H
Hey
so
good,
that's
a
great
question:
you
would
you
would
really
you
would
literally
subscribe.
You
would
probably
subscribe
to
the
stream.
H
Someone
needs
to
go
and
consolidate
those
events
for
you.
If
you
want
to
have
events
from
300
individual
devices
out
of
900,
you
probably
want
to
go
and
turn
those
subscriptions
on
or
off
individually
or
you
care
about
the
entirety
of
those
and
then
and
then
we're
talking
about
individual
subscriptions,
which
means
you
haven't.
You
haven't
a
subscription
manager
and
the
subscription
manager.
H
You
pass
the
the
the
the
name
of
that
device,
the
the
uri
of
that
device,
the
identifier
to
the
subscription
manager
as
parameter
in
that
case,
and
then
you
are
directing
events
from
that
device
into
your
direction.
H
If
you
are
interested
in
events
from
all
of
those
devices,
then
you
might
be
subscribing
to
an
aggregator
which
is
doing
that
job
for
you
already
in
in
an
actual
system.
I,
yes!
So
if
you
have
900
devices
you
want
to
have
have
events
from
300
of
them.
H
You
have
to
have
a
place
so
either
you
have
to
have
a
place
that
manages
all
those
all
those
relationships
for
you.
That
means
that
you
are
only
interested
in
300
or
you
have
a
you
individually.
You
have
individual
subscriptions
on
them.
H
But
I
don't
think
I
don't
think
you
get
around
you
get
around
having
either
subscribing
to
an
aggregator
and
then
getting
alerts
that
are
derivatives
of
that
stream,
but
that
no
longer
means
you're
subscribing
to
devices
you're
actually
subscribing
to
alerts
that
are
produced
out
of
the
aggregation
or
that
you
are
really
going
to.
You
know
wherever
those
those
those
events
land
in
your
infrastructure
and
then
individually,
being
interested
in
in
that
device
or
that
device
and
that
device.
That
means
you
have
literally
the
subscription
per
device.
J
E
F
Of
producing
events
filtering
events
out
as
far
up
the
producer
chain
as
possible.
You
could
have
an
aggregator
that
accepts
these
kind
of
wild
card
events.
It
understands
the
things
that
are
connected
to
it
and
it
can
propagate
subscriptions
up.
As
you
know,
the
filters
become
loosened.
F
Right
yeah,
this
is
that's
a
detail
that
could
be
hidden
from
the
initial
subscription
request
right.
H
Yes,
so
so,
if
you
really,
if
we,
if
we
are
going
down
the
the
so
so
what
your
ex,
what
you're
saying
is
something
that
I've
heard
a
lot
so
far
kind
of
in
theory,
but
I
haven't
seen
much
yet
and
that
is,
for
instance,
this
whole
notion
of
5g
4
deployed
in
the
network.
Smart
routers
that
can
deal
with
application
level
constructs
so
that
you
could
go
and
and
say
you
know.
H
H
C
You're
looking
for
you're,
not
you
can
just
proxy
because
then
you
can
have
a
different
security
context
and
if
your
interrupt
ability
with
different
company,
basically
when
I
connect
to
github,
I
need
to
have
my
github
tokens,
while
basically
when
I
forward
it
to
my
own
customer,
I
want
them
to
have.
I
don't
know
and
another
company
token
that
is
different
from
the
github
token.
So
and
I
don't
want
to
rewrap
everything.
H
H
H
A
Right
and
that's
when
I
start
getting
confused,
because
at
that
point
I'm
wondering
because
I
think
we're
all
in
agreement
that
these
that
the
source
value
in
this
stream
of
events
coming
from
this
one
subscription
in
some
cases
may
be
the
same
value
every
single
time
or
in
something.
That's
more
like
an
aggregation
case.
It
actually
could
change
its
value
over
time
depending
on
who
actually
generated
the
event.
H
A
H
Because
the
source
here
actually
does
work,
it
activates,
something
if
you
put
it
in
a
filter,
then
you
are
assuming
that
the
events
from
that
from
that
source
are
already
coming.
H
H
If
all
the
storage
accounts
that
exist
in
azure,
with
all
the
containers
and
we're
talking
about.
You
know:
trillions
of
objects.
If
every
single
one
of
them
were
throwing
events
up
into
our
system
without
having
been
having
been
asked
to
go
and
start
doing
that,
then
the
system
would
just
be
swamped
in.
I
don't
know
how
many
trillions
of
events
every
second
just
because
every
object
is
starting
to
throw
events
up,
so
that
is
far
rather
impractical.
So
so
we
need
to.
We
need
to
keep
track
of
of.
H
Is
there
actually
interest
in
events
from
that
source,
so
we
can
go
and
activate
the
event
admission
and
when
the,
when
the
interest
goes
away,
when
the
subscription
is
being
deleted
and
the
last
subscription
effectively
for
that
particular
object
is
gone,
then
we
also
stop
stop
emitting
those
events
again.
H
K
Are
showing
up
in
your
environment
or
to
are
actually
being
delivered?
You
could
proactively
push
the
filter
out
to
a
series
of
sources
that
you're
aggregating
from.
K
K
So
you,
the
the
aggregator,
can
know
whether
a
certain
source
can
do
constraining
in
real
time,
but
also
there's
some,
like
you
know,
take
your
your
blob
storage
example.
You
know.
Maybe
I
would
think
that
the
default
event
or
the
default
case,
if
I
don't
supply
a
blob
that
I
want
to
be
my
source,
is
that
I
would
get
all
public
potentially
and
although
you
could
maybe
make
that
more
of
an
opt-in,
but
anyway
that
I
would
get
all
events
in
my
subscription
scope.
K
All
the
things
that
I
privately
have
access
to.
All
of
them
can
come
to
me.
If
I
don't
supply
any
filter,
that's
what
I
would
expect.
I
wouldn't
expect
to
have
to
explicitly
declare
this
one
and
this
one
and
this
one
and
this
one
everything
I
have
oh
by
the
way
those
are
dynamic.
We
created
some
time.
So
therefore,
I'm
going
to
be
missing,
yeah.
K
Traffic-
I
completely
appreciate
that
you
do.
I
think
that
you
could.
You
could
manage
that
internally.
K
Right,
yeah,
it's
you're,
just
not
gonna,
be
able
to
do
that.
There's
there's
too
much
and
it
would
cause
architectural
problems
and
you
know
choke
off
the
flow
yes,
but
so
you're
going
to
have
a
more
complicated
implementation
behind
the
scenes.
It's
going
to
be
that
the
subscription
api
is
going
to
facilitate
kind
of
propagating
knowing
the
details
of
all
of
the
sources
that
could
potentially
produce
the
events
that
you're
that
are
being
subscribed
to
and
pushing
this
subscription
to
those
places.
H
So
you're
saying
that
the
so
I
I
shall
infer
the
candidates
who
might
who
might
be,
who
might
be
requested
to
go
on,
admit,
events
from
the
filter.
K
Well,
that
person
that
that
whatever
endpoint
is
configured
is
going
to
be
inundated,
but
it
might
be
a
valid
thing.
Maybe
what
I
want
to
do
is
do
something
like
archive
everything
archive
all
activity,
in
my
account
some
for
some
kind
of
an
auditing
purpose.
K
Well,
as
the
subscription
provider
you,
I
would
hope
you
would
require
me
to
identify
myself
and
that
provides
a
security
context.
That's
why
I
was
talking
earlier
about
the
public
publicly
available
things
and
then
also
what
I,
as
with
the
security
context,
I
bring
in
aloud.
H
But
the
security
context
is
so
when
I
go
to
the
security
context.
So
when
I
log
into
the
azure
portal
I
have,
I
don't
know
40
different
subscriptions
that
I
have
access
to
yeah
and
each
subscription
is
obviously
a
a
separate
azure
tenant,
which
means,
if
I
see.
H
K
It's
sufficient
to
what
is
accessible
to
the
subscriber
now
as
a
subscriber
and
as
an
implementer
of
the
subscription
api
you
might
want
to
require
subscription
as
a
filter.
K
H
How
does
that,
then?
How
does
that?
Okay?
So
so,
if
we
don't
want
to
provide
any
scoping
whatsoever
in
the
subscriptions
gesture,
how
do
I
know
that
a
store
that
a
an
event
that
I'm
getting
has
been
delivered
by
based
on
a
particular
subscription.
H
Yeah
I
mean
if,
if
I,
if
I,
if
I
haven't,
if
I
have
a
subscription
api
which
is
clearly
associated
with
the
source,
then
I
know
when
I
get
an
event
and
the
source
is
filled
out
where
they
came
from.
So
if
I
have
a
subscription-
and
I
do
this
on
a
particular
blob
container
then-
and
I
get
an
event
that
I
know
that
I
have
the
where
that
came
from-
I
can
also.
H
I
can
also
make
sure
that
the
combination
of
destination-
and
so
if
I
do
push
delivery,
that
the
destination
of
source
and
target
is
unique
within
the
system.
So
I
don't
don't
deliver
double.
A
F
First,
and
so
I'm
sorry,
I
should
have
brought
this
up
much
earlier,
but
I
know
we're
talking
about
this
imperative
api,
but,
like
anyone
have
any
heart
to
throw
the
entire
thing
out
and
kind
of
move
to
a
resource
model.
F
Can
what
if
we
described
instead
of
this,
the
current
api
that
we've
been
kind
of
working
on
what,
if
it
was
declarative,
all
right,
like
kind
of
kubernetes
resource
based,
doesn't
mean
that
it
has
to
be
in
kubernetes.
But
the
thing
that
would
implement
the
api
would
speak
similar
api
to
what.
N
A
F
H
But
you
still
have
relationships
I
mean.
Ultimately,
the
declarative
model
is
like.
If
I
look
at
kubernetes,
that
is
a
hierarchical
or
relation
relational
model,
it's
ultimately
what
what
kubernetes
gives
you
it
gives
you
a
database,
that's
describing
all
of
your
assets.
H
That
yeah,
but
then
then
we
still
need
to
go
and
establish.
We
still
need
to
establish
a
subscription
that
will
stably
deliver
events
to
you
somehow
and
how
do
we
establish
that
right?
The
subscription.
F
A
May
be
useful,
if
maybe
you
can
write
up
an
example
and
explain
how
things
would
change
because,
like
I
said,
I
personally
don't
understand
how
it
changes
anything
because,
even
in
k
native,
when
you
set
up
a
subscription
or
an
event
source,
sorry
or
something
like
a
broker
right,
where
it
has
filters
and
stuff
like
that
it.
It
looks
the
same
to
me
as
this.
O
C
M
A
I
was
going
to
say
was:
thank
you
clemens,
very
much
for
your
for
your
description
before,
because
that
really
helped
me
solidify
in
terms
of
what
you're
thinking
it
just.
It
was
eluding
me
for
some
reason
and
that
now
I
have
some
clarity
and
that's
why
I
put
it
down
here,
because
I
realized
that
when
you
were
talking
about
needing
a
source
as
a
first
class
thing,
because
you
need
to
know
which
thing
to
turn
on
the
events
or
you
know
which
thing
to
go
talk
to
to
turn
on
the
events.
A
I
just
realized.
That's
exactly
what
these
two
things
are
doing
in
essence
right
they
aren't
describing
the
source,
it's
just
not
calling
it
source
right
and
that
that's
why
I
moved
it
down
to
here,
because
I've
realized
that
you
may
or
may
not
want
to
do
that,
and
it
does
become
sort
of
a
configuration
option
kind
of
thing
now,
whether
it's
top
level
or
in
here
we
can
just.
We
can
discuss
that.
But
the
one
thing
about
this
that
I
thought
was
interesting
was
later
on
during
my
ramblings.
A
At
the
very
very
end,
I
I
thought.
Okay,
if
someone
does
support
filtering,
they
could
have
technically
expressed
the
entire
subscription.
This
way
right,
where
the
owner
and
repo
which
basically
the
source,
are
part
of
the
filtered
dialects,
and
I
think
this
may
be
what
eric
was
leading
to,
which
is
it's
the
subscription
manager's
job
to
look
at
this
and
say:
oh,
you
know
what
I'm
going
to
have
to
extract
this
information
and
go
talk
to
this
particular
source
and
tell
him
to
go
turn
on
his
event
stream.
L
A
Saying
is
that
right,
eric
yeah,
that's
about
right,
okay,
and,
if
that's
true,
I
do
think
that
it's
a
completely
valid
choice,
but
I'm
not
sure
I
want
to
force
that
on
everybody
either,
because
that's
also
a
very
expensive
choice
right,
especially
if
you're
living
in
I
think
clemens
your
world,
which
is
filtering,
is
simply
a
filter
and
nothing
more
right.
Those.
H
A
Exactly
right,
I'm
not
necessarily
where
I'm
going
with
this
other
than
I'm
getting
a
little
more
clarity.
Now,
and
that's
why
I
think
if
I
was
to
sort
of
try
to
summarize
where
I
think
my
head
is
going,
is
that
source
should
be
a
config
thing,
but
it
should
be
optional
and
I
think
the
discovery
metadata
for
this
particular
subscription
manager
needs
to
advertise
whether
he
needs
or
requires
source.
A
I
I
do
have
a
get
out
of
jail
free
card,
because
the
only
the
only
female
on
our
calls
ginger
is
perfectly
okay
with
it.
So
anyway,
correlation
and
causation
doug.
I
know
anyway,
both
dudes
die
hard
anyway.
Think
about
that
for
a
minute.
Clemens
always
keep
going
to
the
queue
and
well
your
hands
up
next
yeah.
L
You
kind
of
took
a
step
at
the
point.
I
was
making
a
plus
one
on
the
resource
model
idea,
because
I
think
eventually,
what
we
have
to
think
about
is
the
the
model
of
producers,
sources,
types
events
and
so
on,
and
whether
or
not
we
call
that
config
or
make
them
top
level
entities
in
this
subscription.
I
don't
think
it
makes
a
difference.
L
I
am
hesitating
on
the
filters,
because
that
could
include
a
nasty
language
and
could
make
it
really
difficult
to
identify
this
was,
but
if
a
source
is
identified-
and
I
mean
explicitly-
I'm
I'm
good
with
this-
and
I
see
where
clemens,
where
you're
going
but
again,
where
do
I
have
when
I
have
aggregators
where
sources
go
on
and
off
even
during
my
subscription?
L
Maybe
I
don't
want
to
have
that
mandatory.
So
I
don't
think
this
should
be
mandatory
and
another
thing
why
this
shouldn't
be
mandatory
is
that
currently
the
discovery
has
no
mention
of
source,
I'm
not
sure
if
in
some
people's
heads
the
service
is
equivalent
to
source,
but
I
think
it
represents
something
that
can
front
several
sources.
Much
like
a
producer
can
take
over
the
event
generation
for
a
couple
of
sources
and
could
also
be
spread
in
a
distributed
system
where
multiple
producers
produce
the
same
source.
L
D
We
have
source
there
as
a
source,
template
or
pattern.
I
keep
forgetting
what
its
name.
Yes,
oh,
wait.
A
minute
hold.
A
A
L
But
it's
not
mandatory,
so
I
wouldn't
know
how
so
point
being
is
there
should
at
least
be
the
any
source
or
star
field
wild
card
to
subscribe
to
sources.
A
H
Yeah,
it's
it's
definitely
optional
like
so,
if
you,
if
you
have
if
you,
if,
if
this
is
your
only
choice,
if
if
the
thing
you
are
interacting
with
is
the
thing
is
actually
that's
emitting
the
events,
then
the
source
is
implied,
it
is
the
source
which
means
you
don't
need
to
go
and
specify
it.
So
this
is
really
only
if
the
subscription
manager
is
acting
on
behalf
of
ex
of
sources
that
are
not
itself,
then
you
would
have
to
go
and
refer
or
refer
to
the
sources.
Somehow.
D
Good,
I
was
wondering
exactly
also
if
it
should
be
the
service
instead,
because
for
discovery
we
said
that
source
might
be.
Very
fine.
Grain
might
be
hard
to
even
list
all
sources
so
always
require
either
a
full
match
or
leave
it
out.
It
seems
a
bit
I
don't
know.
I
would
also
like
to
have
something
like
white
cards.
P
D
F
K
Yeah,
thank
you,
as
I
didn't
come
into
this
call
kind
of
having
made
this
distinction,
but
I
I
and
that'll
end
up
being
relevant
in
a
second,
but
I
I
was
kind
of
a
little
opposed
to
what
you
did
in
config
doug,
because
what
I
was
seeing
there
seems
to
belong
more
in
filters
as
far
as
I'm
concerned,
and
then
there
would
be
a
very
small
translation
into
those,
as
you
know,
whatever
the
github
api
uses
them
for,
so
it
would
be
still
very,
very
low
effort
the
same
way
that
they're
gonna
have
to
pull
up
this
jason
and
do
the
right
thing
with
it
right.
K
But
one
of
the
things
I
didn't
come
into
the
call
with
was
this
notion
of
both
a
static
and
dynamic
layer
of
kind
of
the
application
of
what
events
I'm
selecting.
L
K
And
to
be
a
little
more
specific
about
that
they're
they're,
we
are
trying
to
describe
an
api
that
is
going
to
declare
the
correct
behavior
across
a
whole
set
of
scenarios
and
a
lot
of
them.
We
won't,
we
won't
know
their
implement,
we
can't
know
their
implementation
and
in
fact
some
of
the
filters
are
going
to
be
a
con.
Sorry.
K
So
you
know,
for
example,
if
everything's
running
through
some
kind
of
an
event
queue
or
you
know
kafka
or
whatever
you
can
know
what
messages
are
routed
into
that
event
queue,
but
within
that
subset,
you're
going
to
have
to
if
only
a
subset
of
the
events
are
being
requested
or
filtered
to
then
you're
going
to
have
to
sit
there
and
look
at
everyone
to
pick
up
the
right
ones,
and
so
this
is
what
I
mean
about
kind
of
the
the
static
versus
the
dynamic.
K
H
H
The
acquisition
of
those
events
somehow
needs
to
have
some
way
of
scoping
and
that's
and
that's
what
I
that's
what
I
was
missing.
A
Yeah
I
like
the
way
you
phrased
it
eric.
Thank
you,
but
so
let
me
back
up,
though,
actually
first
manuel
is
your
hand
up.
Is
that
old
or
is
that
new?
A
So
that's
old?
Okay,
that's
what
I
thought:
okay,
so
eric!
If
you
start
off
the
conversation
by
saying
you
were
uncomfortable
at
first
with
what
I
wrote
here,
but
by
the
end,
are
you
actually,
okay
with
that?
Because
of
the
because
of
what
clemens
has
been
pushing
pushing
us
on,
which
is,
he
needs
a
way
to
get
that,
in
essence,
static
data
to
know
exactly
which
thing
to
turn
on
the
events
for.
K
With
this
style
to
me,
I
think
that
both
config
and
filters
are
going
to
be
pretty
specific
to
whoever
whatever
subscription
you're
speaking
to
so
exactly
how
each
implementer
wants
to
make
that
choice,
making
static
things,
making
static
things
go
into
config
and
the
dynamic
ones
go
into
filters
that
that
seems
like
a
reasonable
way.
For
that
to
happen.
K
I
definitely
have
been
thinking
a
little
differently
about
it
previously,
but
it
seems
reasonable
enough.
I'm
I'm
far
more
okay
with
it
than
I
was
okay
but
yeah,
but
I
had.
A
A
A
Model
we
have,
which
is
you
create
the
event?
Then
you
filter
the
event.
Then
you
send
the
event,
and
if
we
be
a
little
more
explicit
about
it
and
say
you
know,
filters
are
meant
strictly
for
filtering
a
stream.
You
already
have
a
list
of
events
flowing
through
it
and
therefore
just
reducing
that
down
they're,
not
necessarily
for
controlling
which
events
get
generated
per
se.
A
I
think
that
might
help
add
some
clarity,
but
at
the
same
time
I
think
a
particular
subscription
manager
could
choose
could
could
still
choose
to
say
you
know
what
I'm
still
going
to
do
everything
as
a
filter,
because
the
way
I
chose
to
implement
everything
into
the
covers
it
is
a
filter,
and
so
when
you
subscribe
to
one
version
of
github,
it
may
look
like
this,
but
another
version
of
github
may
actually
look
like
this
if
they
choose
to-
and
I
think
we
need
to
allow
for
both.
A
But
I
think
the
the
the
metadata
for
the
discovery
service
just
needs
to
be
very
clear
about
what
they're
expecting
so,
for
example,
the
metadata
for
this.
This
one
may
not
have
any
config
options
at
all
in
in
this
section,
whereas
the
normal
github
one
may
it
may
mention
you,
know
repo
owner
or
may
call
it
source
it's
up
to
that.
H
But
you
should,
I
think,
what
you're
what
you're
doing
here
is.
You
are,
if
you
talk
about,
if
we
stick
with
github
right,
you're
moving
a
you're
effectively
shifting
lever
over
the
graph
that
is,
that
is,
is
give
up
right,
and
that
is
it
in
in
in.
If
we
look
at
this
at
this
here
right,
you
are
placing
the
subscription
at
the
root
of
github,
and
I'm
now
filtering
everything
down
to
the
exact
events
that
you
have,
but
everything
in
github
is
a
candidate
that
is
that
is
the
I'll.
H
Give
you
an
exa
I'll,
give
you
an
example
in
in
a
parallel
example
in
broker
world
right.
That
is
how
mqtt
works
in
mptt.
H
H
The
the
topic
name,
the
topic
prefix
actually
in
mqtt-
is
a
pure
filter
condition
versus
a
a
topic
in
mq,
where
you
are
creating
a
channel
for
messages
that
you're
sending
through
that
particular
channel,
and
then
you
can
go
and
create
a
subscription
on
that
topic,
which
will
then
go
and
allow
you
to
go
and
filter
all
the
messages
are
coming
into
that
topic,
but
none
of
the
messages
that
are
going
into
a
different
topic
right,
that's
the
so
so
there's
this
there's
this
this
wide
open
space,
where
you
have
this
giant
this
giant
space
where
all
the
events
exist
and
you
can
go
and
just
filter
into
them,
or
you
have
this
very
explicit,
split
between
a
topic
which
means
a
channel
through
which
which
events
flow
onto
which
you
can
then
subscribe
and
then
and
then
filter,
filter,
further
things
down,
which
is
a
concept
that
doesn't
exist
in
mqtt.
H
I'm
saying
yes,
there
is
that
I
think
there
is
a.
I
think
this
this
can
exist
and
the
other
one
are
exist,
but
I
think
those
are
the
same
model.
It's
just
it's
just
here
in
this
picture,
you
are
choosing
to
simply
subscribe
at
the
root
of
whatever
scope
that
subscription
manager
has,
and
in
the
other
example,
you
are
subscribing
to
a
subset
of
candidate
events
which
are
then
being
filtered
down.
L
A
A
But
that's
that's
because
they
chose
to
implement
it
because
it's
very
possible
for
all
we
know.
Actually
github
may
actually
generate
an
event
for
every
single
repo
for
every
single
thing
and
actually
do
it
do
everything
through
filters
for
all
we
know
we
just
don't
know,
but
that's:
okay,
yeah,
okay
and
okay.
A
So
for
those
folks
who
are
joining
the
call,
let's
actually,
let's
wait
another
two
minutes
before
I
get
into
this,
since
we
normally
till
three
after
anyway,
so
back
to
this
clemens,
you
you're
originally
talking
about
sources
being
some
top
level
thing.
But
what
do
you
think
about
it
being
under
config?
Since
that's
it's
sort
of
controlling
which
thing
or
how
events
are
being
generated.
H
The
only
reason
why
I'm
a
little
hesitant
for
that
to
be
under
config
is
that
config
was
I
thought
of
config
as
a
very
generic
bucket
of
of
key
values
that
you
would
hand
to
a
to
the
application
to
to
to
the
thing,
and
it
would
you
would
then
configure
it.
So
this
for
me
was.
H
I
was
thinking
that
that
that
that
would
be
also
something
that
just
doesn't
sit
side
by
side
with
all
the
that
config
stuff,
but
with
is
also
first
class
in
in
the
subscription.
That's
that's
the
distinction.
Ultimately,
I
think
of
this
as
a
more
or
less
as
a
naming
decision
decision,
and
as
long
as
there
is
a
well-defined
place
for
it,
I'm
I'm
I'm
okay
either
way,
I
just
thought
of
the
conflict
bucket
as
something
that
is
more
free-form
without
anything
specific
being
defined
in
that.
In
it,
okay.
A
Oh
yeah,
I
guess
we
could.
We
can,
I
guess,
noodle,
on
the
exact
location
later,
but
I
was
assuming
if
it
was
under
here
we
would
say
there
there's
a
list
of
predefined
ones
that
are
common
and
and
they
would
look
a
lot
like
the
cloud
events
one,
and
so
I
guess
actually,
let's
just
pause
there
for
a
sec,
because
I
know
I
got
people
joining
new.
What
we
decided
to
do
was
to
take
the
top
of
the
hour
to
go
back
and
exit
for
a
minute.
A
The
deep
dive
discussions
and
talk
about
sort
of
the
governance
type
thing
that
way,
people
who
can
only
stay
for
this
one
hour,
the
normal
hour
won't
miss
out
on
that
part
of
the
discussions
and
then
we'll
jump
back
to
the
normal
deep
dive
discussions
is
that,
okay
with
everybody
all
right,
so
anything
from
the
community,
people
want
to
bring
up.
That's
not
on
the
agenda.
A
Okay,
eu,
so
we
have
coming
up
fast
but
keep
in
mind
remy's
volunteered
to
talk.
If
somebody
else
would
like
to
talk,
please
let
me
know
we
have
until
the
seventh
to
let
that
to
let
them
know
we
do
have
an
sdk
called
technically
after
this
one.
We're
gonna
do
the
exact
same
thing
for
that
call
at
the
very
at
the
top
of
the
next
hour,
we'll
switch
over
there.
A
We
do
have
one
topic
as
of
right
now,
but
when
that's
done,
we'll
switch
back
to
the
deep
dive
of
the
design
discussion,
discovery
interop,
I
don't
think,
there's
anything
much
to
mention
from
last
week
unless
someone
else
was
on
the
call
can
think
of
anything.
Q
A
Okay,
any
questions
for
them
all
right
cool.
Thank
you.
Just
a
heads
up,
if
you're
interested
in
the
discussion
about
the
linux
foundation
mentorship
or
the
google
summer
of
code
thing
that
is
as
of
right
now,
I
believe
the
only
topic
in
the
sdk
call,
so
if
you're
interested
in
that
stay
on
for
the
sdk
call
at
the
top
of
the
next
hour.
A
L
I
have
to
refresh
my
own
memory,
so
here
we
go
with
the
other
discussion.
If
you
want.
L
Yeah,
let's
look
at
the
issue.
I
think
it
will
cut
it
down.
Oh
yeah,
so
spec
versions
said
to
be
a
list
of
strings,
but
actually
the
specification
was
using
an
object,
so
that
needs
to
be
fixed.
Then
subscription
dialects,
the
description
or
the
the
type
has
a
typo.
It's
values,
and
this
has
to
be
fixed,
but
also
in
other
occasions,
list
is
used
and
it's
not
a
uri
list
of
ui
references
but
strings
so
just
say
list
of
string
values
then
to
align
it
with
the
specification.
L
The
fields
id
epoc
and
subscription
dialect
were
missing
all
together
and
the
there
is
one
more
complicated
thing
that
is,
the
spec
currently
lists
all
the
parameters,
and
then
we
have
one
subtype
so
to
say
a
sub-object
that
is
called
types
and
the
fields
of
that
object
are
listed
alongside
the
top-level
parameters
in
the
specs.
So
this
should
be
separated
in
the
spec
markdown.
L
Also,
I
I
would
switch
the
name
type
to
event
type
to
make
the
schema
more
clear
of
what
this
object
is
type
kind
of
confusing.
So
these
are
the
changes.
Okay,.
A
M
L
Yeah
there
were
parameters
in
the
request
body
that
no
sorry
not
request
buddy
for
operations
in
open
api
spec.
That
appeared
on
the
path
of
the
http
request
and
those
parameters
cannot
be
omitted
in
any
case,
so
there
needs
to
be
required
true,
as
mandated
by
the
open
api
spec.
So
these
are
the
two
occasions
you
can
see
here
and
then
also
there
was
what's
the
other
one
I
think
the
any
off
I
reverted.
So
if
that's
the
only
change
left,
then
yes,
okay,
any
questions
or
comments.
A
A
A
A
Okay,
I
did
decide
to
keep
the
protobuf
spec
in
there
because
that's
not
as
much
a
work
in
progress,
it's
kind
of
done,
but
I
did
change
it
to
say
to
release
candidate
and
I
left
it
in
the
101
branch.
I
wasn't
sure
which
way
people
would
want
to
go
on
that,
but
I
think
everything
else
is
what
I
already
said:
remove
the
new
respects
and
change
and
remove
the
work
and
draft
stuff.
Does
anybody
have
an
opinion
on
this?
One
think
I
chose
the
wrong
direction
to
go
on
this.
A
A
R
R
It's
it's
in
the
it's
in
the
issue.
Is
it
hold
on
the.
P
C
M
A
R
Yeah,
as
I
said,
it's
pretty
similar
to
the
other
to
your
solution
with
the
difference,
and
here
we
are
using
the
the
where
clause
syntax
of
this
sql,
and
I
took
some
parts
from
the
from
the
spec
that
clemens
proposed.
I
recognize
the
wording.
R
R
R
A
A
All
right
cool,
thank
you
and
that's
it.
Okay.
So
before
we
jump
back
to
the
design
deep
dive
discussions,
were
there
any
of
the
topics,
people
wanted
to
bring
up.
A
Okay,
in
that
case,
if
you're
not
interested
in
the
sdk
stuff
and
you're
not
interested
in
the
deep
dive
which
shame
on
you,
if
you're
not
you're,
free
to
leave
other
than
make
sure
if
you
do
leave,
I
have
you
mark
down
for
attendance,
so
let
me
just
quickly
run
through
it,
since
I
usually
do
this
verbally
anyway.
So
lance
I
got
you.
Thank
you
all
right.
Lucas
are
you
there.
A
A
I
don't,
I
think,
he's
new.
I
lost
him.
Okay,
did
I
miss
anybody
else?
Oh
lionel.
I
apologize.
Thank
you
lionel.
Okay,
anybody
else.
A
Okay.
So,
where
we're
left
off,
it's
not
like
clemens,
you
may
have
been
okay
with
this
being
under
config,
but
let
me
poke
on
the
other
people
on
the
group.
Did
anybody
else
have
an
opinion
about
that?
Whether
it
should
be
a
top
level,
because
it's
special
or
whether
it's
just
a
predefined
one
or
a
well-known
config.
A
Maybe
not
okay
manuel
no!
I
do
come.
A
L
I
think
of
it,
since
there
is
the
basic
filter
type
that
allows
any
of
the
cloud
events
properties
to
be
filtered
upon.
I
think
source
really
sort
of
belongs
there
or
should
be
a
top
level
feeling,
because
config
is
really
very
specific.
F
Yeah
I
agree
with
clemens
around
config.
Is
this
very
opaque
grab
bag
of
config
that
is
vendor-specific
or
whatever
the
service
you're
talking
to,
and
and
if
you
want
to
make
a
very
first-class
thing,
we
should
pop
it
out
to
some
place.
That's
not
in
this
generic
grab
bag
thing.
A
Okay,
any
objection,
then,
to
removing
it
or
not
putting
it
under
config
and
making
a
top
level
thing
done.
Cool
okay,
so
I
then
have
another
question
to
follow
on
then
is
source
the
okay
two
things,
the
first
one
is
source,
the
only
cloud
event
property,
that's
special,
or
do
we
need
to
take
into
account
any
other
ones.
L
A
A
H
We
have
we
have
in
our
just
just
to
cite
prior
art.
Our
subscription
gesture
for
in
event
grid
has
the
the
source
effectively
and
then
also
the
type
and
then
and
from
there,
on
it's
all
filters.
So
if
you
you
subscribe
to
on
on
a
particular
source,
you
subscribe
to
all
events
or
a
particular
event,
which
means
you
leave
this
off
you
or
you
don't,
and
then
you
and
then
from
there.
H
A
H
How
do
we,
I
would
probably
make
that
here
or
our,
so
this
is
like
if
I
had
the
choice
again,
so
I
would
probably
make
that
all
right.
J
Yeah
and
I
can
say
at
twilio,
we
have
event
streams,
which
is
basically
an
array
of
events,
specific
event,
types
that
you
subscribe
to.
So
it's
aligned
there
too.
A
Okay,
so
timber's
asking
why
an
array
can
you
elaborate
anymore
in
terms
of
why
you're
asking
given
what
we
talked
about?
How
something
like
github
allows
you
to
specify
more
than
one.
Q
H
A
F
A
Yeah,
I
think
I
think
it
was
it
took
a
while
to
understand
where
each
of
us
are
coming
from,
but
I
think
we're
getting
there.
This
is
good
okay,
so
I
think
where
we
landed
is
watch.
Let
me
back
up.
Are
there
other
convent
properties
that
we
want
to
possibly
raise
to
the
top
level.
D
K
A
K
My
question
is:
what
is
we're,
having
kind
of
this
debate
over
whether
something's
important
enough
to
put
in
at
the
top
level-
and
I
guess
I
was
wondering
what
what
what's
the
basis
for
you
know,
kind
of
at
a
level
up
for
putting
something
there?
I
I
guess
I
I
I
don't
know
I
it's.
I
didn't
raise
an
objection,
but
I
do
think
it's
a
little.
We
I
don't.
I
don't
know
why
we
would
put
source
at
the
top
level
rather
than
in.
H
Yeah,
I
think
what
we
were
with
that
was
that
config
is
a
a
generic
property
bag
that
you
give
to
the
implementation
and
that
implement
and
that
might
contain
application
specific
information
about
about
how
to
configure
the
effectively
how
to
configure
the
source.
For,
for
you
know,
by
what
cadence
it
gives
you
events
or
or
some
other
some
other,
some
other
information
that
you
want
to
give
the
source
specifically.
K
J
M
K
Interested
in
and
that's
why
you
know
originally
doug
putting
the
config
there
as
you
had.
It
seemed
a
little
odd
to
me,
but
I
could
also
see
maybe
if
we
use
config
as
a
space
for
the
static
stuff,
why
that
maybe
makes
sense
or
something
but
then
elevating
some
of
the
cloud
event
attributes
into
the
top
level.
I
mean
I
I
guess
we're
guaranteed
to
have
them
and
but
it,
but
it
doesn't
necessarily
seem
very
clear
why
they're
they're,
I
don't
know
just
my
thoughts.
F
A
You
so,
okay,
as
we
write
this
up,
is
it
very?
Is
it
fair
to
say
then
that
these
types
of
properties
are
for,
as
scott
said,
for
targeting
a
particular
producer
where
these
are
just
for
configuring?
The
producer
yep
is
that.
Does
everybody
agree
with
that
kind
of
a
description,
because
I
think
we
need
to
put
that
into
the
spec
somewhere.
A
Okay,
so
hold
on
a
minute
here:
let's
go
back
to
the
cloud
event,
spec.
K
M
P
A
Because
I
I
got
to
be
honest
with
you
eric
I
I'm
actually,
okay
with
where
we're
landing
or
where
I
think
we're
here,
geez,
I'm
okay,
where
I
think
we're
going
with
this.
But
I
do
agree
with
you.
It
makes
you
very
uncomfortable
because
I
hate
the
idea
of
because
oh
we're
the
spec
authors,
we
can
say
what's
special
but
users
who
use
the
spec
can't
right.
Our
data's
special
and
I've
always
been
bothered
by
that,
and
but
I
also
understand
why
we
landed
where
we
did
right.
F
K
I'm
expressing
it
weekly,
I
my
role
here
is
to
be
a
not-so-dumb
end-user
and
kind
of
serve
as
a
result.
Representative,
I'm
not
really
on
the
block
for
implementing
most
of
this.
These.
F
A
F
And
we
don't
need
to
care
about
the
subscription
config
or
the
events.
So
much.
A
I
never
thought
of
it
that
way,
I
don't
know
if
I
like
it
or
not.
Well,
I
guess
I'm
struggling
with.
Why
would
you
need
to
find
the
discovery
entry
from
this.
F
That
I
think
the
that
is
how
you
find
out.
That's
how
you
know
which
producer
is
going
to
be
subscribed
upon.
F
F
H
Yeah
this
the
service
is
not
necessarily
the
service.
Is
not
the
service
identifies
the
subscription
endpoint
it
doesn't.
It
doesn't
identify
the
the
sources
that
are
available
at
the
at
that
endpoint.
A
A
H
Then
we're
back
to
then
we're
back
to
having
a
I
mean
we
can,
we
can.
We
can
potentially
allow
for
wealth
cards
there.
H
I
would
I
would
personally
not
allow
it,
but
I'm
not
against
having
that
not
necessarily
have
against
that
against
having
that
in
the
spec.
It's
just
I
I
I
I.
I
still
want
to
have
a
clear
differentiation
between
what
what
source
is
here
and
what
what
the
filter
is.
It's
still
about
the
acquisition
of
the
events
and
not
about
filtering
the
acquired
stream
down.
D
J
So
yeah,
what
one
one
practical
example
here
that
might
be
interesting
to
think
about
is
you
you
might
have
a
system
or
a
consumer
that
is
interested
in
subscribing
to
a
source,
but
it
doesn't
it's
not
aware
of
what
the
source
is
right
and-
and
there
are
cases
where
you
want
those
things
to
be
to
be
as
decoupled
as
as
possible
and
the
the
source
might
be
created
and
and
move
through
its
life
cycle
faster
than
the
consumer
can
actually
discover
that
it
exists
in
the
first
place,
and
so
I
think
there
is
maybe
a
case
to
support
the
templarized
and
wild
card
approach
here.
A
A
H
A
H
A
It
has
question
marks.
It
has
why'd,
you
see
stars.
G
H
G
H
A
F
A
That
would
mean
that,
in
order
to
do
this
kind
of
matching
of
the
source
or
the
producer
you'd
have
to
have
a
discovery.
Spec
implementation
there
as
well.
L
That's
totally
new,
I
want
to
say
on
the
initially
with
the
whole
discussion,
I
thought
specifying
a
source,
and
that
is
an
exact
one
meant
that
it
allows
the
subscription
manager
to
make
a
subsequent
or
transient
subscription
to
whatever
the
source
is.
So
I
also
had
a
feeling
that
this
might
being
a
top
level
element
that
this
might
render
the
subscription
valid
or
invalid.
So
when
I
specify
an
exact
source
that
this
is
not
known
to
subscription
manager,
then
it
wouldn't
allow
this.
L
A
J
Okay
and
I
think,
as
long
as
it's
possible
in
filters-
and
you
know,
the
support
of
the
various
dialects
for
filters
are
optional.
I
think
that
gives
enough
flexibility
to
the
implementations
to
choose.
You
know
what
they
want
to
support.
H
Yeah
and
just
just
from
just
going
back
going
back
into
into
implementation
detail
for
a
second.
H
I
can,
I
can
obviously
make
a
subscription
manager
that
can
offer
subscriptions
at
all
kinds
of
levels,
which
means
I'm
again
sticking
to
the
storage,
the
storage,
account
example.
I
can
say
the
source
you
come
to
me
and
say
I
want
the
source
for
this
to
be.
H
H
H
My
source
is
actually
service,
slash
container,
slash
directory,
slash
another
directory,
and
then
I
only
get
events
for
that
scope
with
that
uri
being
the
source,
because
that's
the
thing
I
subscribed
on
and
then
the
subject
being
the
relative
path
from
that
uri
to
the
file
that
was
created.
H
So
I
can.
I
can
create
this.
I
can
create
this
flexibly.
It's
not
that
that
I'm
necessarily
constrained
by
that
the
subscription
manager
can
can
go
and
interpret
and
create
scoping
where
you
know
splitting
up
the
the
the
the
identifier
for
the
thing
that
the
event
is
ultimately
about
between
the
subscription
scope
and
then
the
the
the
remaining
scope
that
is
then
expressed
in
the
subject.
S
Okay,
for
some
reason,
I
will
the
raised
hand
feature
is
gone
from
my
we're
going
to
zoom.
So
I
apologize,
but
I
guess
partly
to
clement's
point,
but
but
I
guess
a
step
back
is
what
I
mean
you
know,
given
that
we're
working
on
the
discovery
spec
and
this
and
workflow,
and
all
these
things
like
what
is
the
you
know
what
what
interoperability
is,
is
required
versus
optional
versus
something
in
between
right,
like
how
many
different
models
are
we
trying
to
shoehorn?
S
What
are
we
trying
to
make
the
sort
of
happy
path
and
try
and
get
people
to
to
to
go
to
versus,
what's
possible
right,
which
I,
which
I
think
I
think
I
think
we
have
to
have
some
kind
of
position
or
bias
or
something
in
what?
What
is
the
expected
flow
of
how
people
are
going
to
use
things,
because
otherwise,
like
it's
too
open-ended
like
too
many
people,
do
too
many
different
things.
A
Yeah,
I
agree
with
you.
I
think
I
think,
and
that's
part
of
I
think
why
this
discussion
has
been
so
good,
because
I
think
we're
trying
to
find
that
balance
between
flexibility
versus
being.
You
know
too
prescriptive
kind
of
thing,
and
that's
why
I
think,
based
upon
let's
say
we
stick
with
what
we
just
have
here
right.
I
probably
would
now
rewrite
this
example.
I
probably
would
not
put
these
down
here
anymore.
A
A
E
K
A
So,
if
you
think
of
one
cool,
thank
you
now
type,
I'm
assuming
I
don't
know
what
type
is
whether
it's
just
a
string
or
uri,
but
whatever
it
is
in
the
c
spec
it's
gonna.
This
is
gonna.
Be
array
of
those
things.
Does
that
sound
right
to
everybody.
A
Okay
and
in
both
cases,
okay
well,
actually-
maybe
not.
I
was
going
to
say
in
both
cases
these
are
optional
for
this,
for
the
subscription
manager
to
support,
but
now
I'm
not
so
sure,
obviously
it's
always
optional
for
the
subscriber
to
include
them
in
their
subscription
request.
But
should
these
be
optional
for
a
event
producer
or
a
subscription
manager
to.
A
H
A
H
A
A
A
T
A
T
Exactly
yeah,
I
mean
there's
situations
where
you're,
just
where
you
don't
have
to
understand
the
where
the
event
is
coming
from.
You
want
to
be
this
sort
of
indifferent
middleman
and
just
distribute
messages
from
whatever
source
comes
in
to
whatever
destination,
based
on,
say,
a
topic
string
or
something
like
that,
which
would
typically
be
the
type
in
this.
In
this
use
case,
the
source
is
irrelevant.
A
A
T
Yeah,
I
mean,
I
guess,
if
you,
if
you're
a
cloud
event
compliant
and
you
you
have
to
accept
the
source
element,
then
that
makes
sense
that
you
know
your
your
filter
would
be
able
to
be
filtered
on
the
on
the
source.
That
makes
sense
to
me.
Yeah.
J
Yeah
I
I
was,
I
was
going
to
say
I
think,
there's
a
difference
between
like
having
semantic
knowledge
about
the
source
and
knowing
what
the
source
string
is,
because,
if
it's
kind
of
a
compliant
like
that
those
are
those
are
in
the
cloud
event
right,
so
they
they
already
have
access
to
that.
So
why
would
that
be?
T
Right
yeah,
I'm
thinking
through
it
just
sort
of
our
implement
implementation
at
solace.
You
know
all
right,
so
baseline
implementation
wouldn't
have
source.
We
don't
really
care
about
the
source.
It's
all
about.
You
know
the
topic
string,
but
if
you
know
we
are
presumably
cloud
event
compliant,
then
we
could
potentially
implement
the
source
as
a
selector
and
then
you
know
that's
our
the
underlying
implementation
of
that
would
be.
You
know
selector
based
essentially,
so
I
guess
yeah
thinking
through
it
more.
I
guess
that
makes
sense.
A
T
A
A
Anybody
want
to
comment
more
on
that.
I
want
to
disagree.
Okay,
just
to
reiterate
we're
on
filters.
We
were
assuming
that
they're
optional
for
this
for
the
for
this
client,
meaning
whether
it
appears
in
the
subscription
request,
but
it's
also
optional,
for
a
manager
to
support
what
do
people
think
about
that
last
part.
A
That
okay
and
just
be,
and
be
clear,
the
minute
something
like
this
appears
or
the
minute
we
make
this
decision
to
me.
That
implies.
We
have
to
add
something
to
the
discovery
spec
so
that
the
subscriber
knows
where
they
can
specify
filter
or
not.
So
that
implies
a
change
in
the
discovery
spec
just
to
let
you
guys
know
where
my
head's
at
so
that
means
a
bigger
pr
or
two
multiple
prs.
A
Okay,
all
right,
I
don't
remember
for
sure
if
we
finished
our
discussion
about,
are
there
other
properties
here
that
we
wanted
to
raise
up?
I
think
was
subject
when
one
someone
mentioned
or
a
subject
too
much
of
a
wild
card
thing,
then
it
makes
no
sense
to
ask
the
person
to
think
of
a
static
value.
A
A
H
Subscription
is
so
subscription
is
not
the
subject
is
not.
The
thing
you
subscribe
on.
The
subject
is
a
description
of
the
the
substructure
inside
of
the
thing
that
you
subscribe
on,
so
the
subject
only
shows
up
in
the
event
itself,
because
it
it
further
qualifies
what
that
event
is,
is
about
within
that
source.
H
L
Anybody
want
to
comment
on
that.
I
want
to
disagree.
It's
an
optional
field
in
cloud
event,
so
I
don't
see
it
the
top
level
field.
A
Oh,
that's
a
good
point
required
versus
optional
you're
right.
That
could
be
a
good
point
too.
So,
let's
just
double
check
sub
type
source;
okay,
those
both
required
good,
just
double
check.
Okay,
anybody
disagree
with
that
conclusion
that
no
other,
no
other
properties
here
should
be
raised
up.
J
Okay,
oh
good,
I'm
still
I'm
still
going
back
and
forth
on
whether
I
think
type
should
be
required
to
support
for
the
manager,
because
I
I
again
the
manager
already
has
the
type
and
especially
when
it's
a
required
field
in
the
cloud
event.
Why?
Wouldn't
we
just
make
that
required
for
the
manager
if
it
already
has
access
to
that.
A
H
I
think
it's,
I
think
it's
optional,
but
why?
Why?
A
A
A
And
acting
on
it
could
mean
adding
it
to
the
filter.
If
you
support
filters,
it
doesn't
necessarily
mean
using
it
as
a
using
it
as
part
of
your
mechanism
to
go
talk
to
some
entity
to
say
turn
on
your.
D
G
L
I
was
under
the
impression
that
any
subscription
that
I
can
issue
to
subscription
manager
can
always
be
filtered
by
any
cloud
event
field
with
the
basic
dialect
that
is
mandatory
to
support,
but
with
the
entire
filters
to
be
optional
for
manager
to
support
that
has
just
gone
so
now
there
is
only
selecting
a
single
source
or
none,
and
luckily
okay,
we,
we
have
the
list
of
types.
L
L
On
what
a
subscription
endpoint
subscription
url
represents,
if
from
that
url,
I
can
only
get
a
limited
amount
of
throughput.
Then
yes,
if
that
means
data
bursts
with
the
either
selecting
the
source
or
then
going
all
the
way
and
not
selecting
a
source
but
getting
the
the
full
blast
from
that
subscription
manager,
I'm
not
sure
if
that's
sufficient,
but
okay,
it
will
turn
out
with
a
little
bit
of
practice,
probably.
A
L
We
had
the
previous
example
of
900
sources
and
then,
whether
or
not
we
want
to
be
able
to
somehow
limit
that
now,
the
only
option
I
have
is
having
a
subscription
for
each
of
the
300
that
I'm
interested
in
or
taking
the
full
plus
of
the
900
resources
and
filtering
it
out
myself.
Because
filters
are
optional
for
manager
to
support.
A
Correct
if
but
see
yes-
and
I
think
I
understand
why
you
as
a
subscriber
can
look
at
that
and
say:
oh
my
gosh-
that's
a
pain
in
the
butt,
but
if
that's
what
this
is,
if
that's
the
only
thing
the
subscription
manager
can
support,
then
you're
stuck
with
it
yeah
right,
because
to
me
the
question
about
whether
it's
optional
for
the
manager
or
not
is
is
what
is
the
burden
we're
going
to
put
on
subscription
managers
and,
in
essence,
filtering?
A
A
This
requires
expression,
processing
right,
even
the
simple
one
that
we
have.
That
still
requires
a
fair
amount
of
processing,
and
that
may
be
a
two
bar
of
a
thing
to
ask.
For
example,
I
can't
ask
that
of
github
today.
As
far
as
I
know
this
I
can-
or
I
can
at
least
encode-
that
into
an
adapter
yeah
I
mean
that's
the
way
I'm
challenged
no.
L
I
understand
and
it's
it's
the
the
burden
of
the
subscription
manager
implementation,
because
that
has
only
sourcebound
interfaces
to
all
the
different
messaging
technologies
underneath
so
yeah
making
filters
possible
could
be
difficult
for
them:
okay,
yeah,
okay
and
I'm
good
for
now.
Okay,.
A
K
Okay,
when
we're
talking
about
making
I'm
sorry,
I'm
talking
a
lot
today,
but
when
we're
talking
about
making
these
filters
kind
of
mandatory,
it's
really
implying
a
certain
mental
model
of
the
consumers
or
the
people.
K
Using
these
things
to
implement
systems,
and-
and
I'm
not
sure
that
I
mean
like
clemens-
was
presenting
a
mental
model
that
really
has
the
source
is
something
that's
really
important,
but
but
I
can
imagine
a
mental
model
that
says
the
subscription
api
that
I'm
talking
to
it's
that
that
system's
job
to
make
sure
that
only
trusted
entities
come
in
here
and
I
I
want
anyone
any
source
to
tell
me
about
things
of
a
certain
type
or
with
a
certain
subject,
or
you
know,
whatever
the
the
criteria.
K
My
model
that
is
relevant
in
my
application
might
be,
and
so
I'm
a
little
uncomfortable
right.
K
I
again
I'm
not
implementing
these
in
implementing
these
things,
so
I
I'm
happy
to
let
the
group
decide
what's
best
for
it,
but
it
seems
like
potentially
there's
a
constraint
and
a
decision
about
what
that
mental
model.
The
application
developer
is
approaching
the
subscription
api
through
and
I'm
not
sure,
that's
an
appropriate
thing
to
constrain,
given
the
kind
of
broad
level
of
engagement
that
this
is
supposed
to
be
specified.
A
Can
you
be
a
little
more
con?
Okay,
first
of
all,
stop
apologizing.
I
love
all
your
input,
your
questions.
This
is
all
good.
That's
why
we
that's
why
doing
these
long
design
discussions
so
so
keep
speaking
up,
but
can
you
give
a
little
more
concreteness
to
what
your
concern
is
like,
maybe
with
an
example
just
so
it's
a
little
more
clear
in
my
head
in
terms
of
what
you're
worried
about
like
we're,
asking
the
the
subscription
manager
to
implement
x
and
that's
gonna,
be
a
problem
for
them.
K
Source
may
be
totally
irrelevant
to
that
subscription
the
implementer
of
the
subscription
api,
but
also
to
the
client
so
in
in
this
case
it's
a
kind
of
meaningless
thing,
and
maybe
that's
just
an
api.
That's
non-compliant
and
nobody
cares
because
no
one
involved
cares,
but
but
in
a
particular
model
we
really
don't
care
about
what
the
source
of
this
information
is.
K
Maybe
I
don't
know,
maybe
it's
something
like
you're
you're,
implementing
a
a
stock
trading
system
that
listens
to
the
events,
describing
news
articles
that
are
being
published
by
all
the
all
the
news
outlets
and-
and
you
don't
really
care
what
the
source
of
the
information
is.
But
you
want
anything
about
any
of
the
stocks
you're
interested
in
or
or
perhaps
you
know
you
don't
care.
K
You
know
about
that
kind
of
filtering
and
you're
going
to
do
some
kind
of
a
aggregation
in
your
system
to
identify
what,
where
you
might
want
to
make
position,
changes
and
and
so
by
making
something
mandatory.
It's
kind
of
implying
that
that
that
is
inherently
a
part
of
the
model
that
you're
coming
with
for
your
application
and
I
yeah
I.
I
don't
know
that
that
necessarily
means
we
shouldn't
make
any
assertions
about
that
model,
but
there
it
is.
O
H
K
J
K
It's
kind
of
I
that's
why
I
go
to
say
a
news
website,
because
they're
listening
to
all
the
sources
that
might
have
relevant
information
about
something
and
they
are
then
writing
up
interesting
articles
that
inform
me
about
the
world
right.
So,
let's
talk.
H
So
so,
if
you,
if
you
were
so,
if
we're,
if
we're
sticking
with
that
example
order,
let's
say
it's
bloomberg
right
then
then
bloomberg
has
a
subscription
mechanism
and
we
have
those
things
with
rss
feeds
where
you
can
go
and
subscribe
to
any
kind
and
kind
of
news.
But
the
scope
at
which
you
subscribe
is
not
the
the
you
know,
the
rainbow
news
or
the
business
news
or
the
sports
news,
but
you
really
want
to
have
all
of
it.
Well
then
you
subscribe
to
all
of
it
to
all
of
it.
H
K
Sure,
okay,
I
mean
I
I
agree
with
that.
I
guess
maybe
maybe
the
the
solution
then
is
there's
a
default
value
of
whatever
the
subscription
api
is
that
you're
subscribing
to.
H
And
that
was
the,
and
that
was
the
implied.
So
some
that's.
I
said
what
I
said
a
while
ago
was,
I
think,
the
resource
the
the
subscription
manager
has
an
implied
notion
of
what
the
source
of
what
the
source
is,
and
if
you
leave
the
source
off
here
in
the
subscription
gesture,
then
it's
automatically
that
source
notion
that
the
that
the
subscription
manager
has
but
there's
always
there.
A
A
One
is
if
you're
not
interested
in
the
sdk
or
in
particular,
you're,
not
interested
in
the
summer
of
code
or
the
mentorship
thing,
but
you're
interested
in
discussion.
Now
is
your
time
for
a
quick
bio
break,
because
I
think
it's
important
that
we
go
back
and
do
what
I
said,
which
is
jump
over
the
sdk
talk
and
see,
if
and
and
get
that
out
of
the
way
for
people
who
are
interested
in
that,
if
that's,
okay
with
everybody
and
so
slinky,
you
can't
escape,
because
I
know
you
that
you're
interested
in
this.
A
So
why
don't?
We
assume
that
we're
gonna
spend
five
minutes
or
so
talking
about
this
and
then
we'll
circle
we'll
come
back
and
continue.
The
deep
dive
discussion
is
that,
okay
with
everybody
yeah
and
I'm
going
to
step
away
for
a
moment,
okay,
so
looking
at
12
after
at
the
worst.
Hopefully,
unless
this
conversation
goes
on
for
a
long
time,
I
don't
think
it
will
so
slinky.
R
So
I'd
have
to
be
honest,
so
summer
code
or
linux
foundation
mentorship
that
doesn't
really
matter.
So
if
we
want
to
go
with
the
links
foundation,
mentorship,
it's
fine,
the
thing
is
that,
to
be
honest,
I
I
I'm
not
sure
we
really
have
some
good
project
for
that,
and
we
need
somebody
that
takes
care
of
mentoring
and
I'm
not
sure
I'll,
be
able
to
to
stay
to
have
time.
For
this
honestly.
R
A
R
Just
to
do
a
quick
recap
for
the
ideas,
my
initial
thoughts
were:
one
is
a
new,
a
new
sdk
in
a
language
that
we
don't
have
and
the
other
one
was
pick
up.
The.
R
The
integration
test
conformance
test
idea
that
we
had
that
we
tried
to
to
bootstrap
at
some
point,
but
then
we
never
had
time
to
to
work
on
it
so
to
extend
the
conformance,
the
send
the
confirmation
test
suite
and
to
actually
use
it
in
every
sdk.
As
far
as
I
know,
no
sdk
except
collage
is
using
the
performance
testing
that
we
developed
that
we
would
struck
so
of
the
two
projects.
A
Okay,
anybody
want
to
speak
up
or
volunteer,
I
should
say
otherwise.
We
will
let
the
idea
just
sort
of
wither
on
the
vine.
R
Well,
by
the
way
the
january
31
is
for
spring,
like
they
do
every
season
as
far
as
understood,
so
the
deadline
of
january
31
is
only
for
the
spring
mentorship,
like
the
one
for
the
summer
is
pushed
on
april
or
and
march.
So
I
don't
recall,
but
it's
far
so
if
you
want
to
discuss
this
again
in
future
and
we
have
people
that
want
to
want
to
chime
in
and
propose
themselves.
A
Q
A
Okay,
you
technically!
I
I
mean
I,
I
don't
know
what
the
process
here
in
terms
of
workgroup
approval,
but
I
can't
imagine
you'd
come
up
with
anything.
That's
really
bad
in
terms
of
what
that
would
hate
the
idea.
So
if
you
can
think
of
one,
I
would
go
ahead
and
just
sign
up
just
keep
in
mind.
The
deadline
is
january.
31St.
A
Just
if
you
do
end
up
doing
it,
just
let
us
know
at
the
normal
working
group
call.
So
if
other
people
want
to
be
involved
in
some
way
they
can
join.
You.
Q
Like
a
general
sdk
question-
and
I
know
on
your
website,
you
have
this
integration
section,
so
you
know
yeah
all
those
companies
and
all
other
places.
You
know
that
that
are
supporting
or
you
using
the
specification.
Q
We
had
a
recent
request
of
like
putting
somebody
on
there.
That's
using
our
sdks
and
I
see
for
cloud
events.
You
guys
are
not
like
doing
that
at
all,
or
at
least
promoting
use
usage
or
other
people
they're
using
it.
I
what
should
I
do
in
that
case,
I.
R
I
personally
in
sdk
java
in
the
readme
at
the
end,
there
is
who's
using
it.
I
just
put
it.
A
A
Okay,
bye
slinky,
so
just
to
to
try
to
wrap
up
the
discussion
you're
having
there
eric
before
we
got
sidetracked
for
a
sec,
I
had
to
admit
I
got
a
little
little
loss
when
you're
talking
about
your
concern,
because
I
wasn't
100
clear
to
me
when
you're
talking
about
what
you
may
want
to
sort
of
get
events
for
whether
you're
talking
as
a
subscription
manager
or
as
a
subscriber,
and
I'm
looking
at
this
strictly
as
a
subscription
manager.
A
At
this
point
in
time,
because
I
think
you
were
focusing
on
this
part
right,
whether
it's
required
for
the
manager
to
support,
and
are
you
suggesting
that
there
are
cases
where
a
subscription
manager
can't
do
any
kind
of
filtering
on
the
events
he
that
it
may
receive?
If,
if
it's
an
aggregator
or
something
like
that,
were
you
asked
something?
Maybe
too
big,
of
a
burden
to
ask
of
them.
K
I
I
think
what
I
was
saying,
because
I
think
that's
a
good.
I
was
probably
losing
track
of
that
distinction,
because
I'm
largely
looking
at
things
for
a
client
perspective,
but
there's
I
it
seemed
to
me
that
there
was
part
of
the
use
case
that
made
it
not
valuable
for
the
manager
to
hand
have
explicit
handling
of
source
that
that
source
would
be
required,
supported
and,
and
so
you
know,
they
could
implement
support
to
be
spec
compliant,
but
not
that
doesn't
make
it
useful
and
and
so
what?
K
What?
In
the
sense
that
is,
is
saying
you
know
if
you're
not
using
this.
If
this
isn't
important
to
how,
in
your
case,
events
are
filtered
that
you're
doing
it
wrong
and
I'm
not
sure.
I
don't
think
that
the
group
would
want
to
say
that,
but
I,
but
maybe
I'm
I'm-
not
thinking
deeply
enough
about
this.
So
so
that's
that's
why
I
was
bringing
up
kind
of
the
mental
models
people
are
approaching.
K
Their
implementation
with
is
is
because
that
then,
the
way
that
the
managers
are
constrained
leads
to
a
pretty
strong
opinion
about
the
api
issues.
J
I
have
one
one
thought
here,
which
is:
I
actually
think
it's
okay
and
in
some
ways,
important
to
have
opinions
about
the
the
mental
model
and
how
things
are
structured,
and
I
think
that's
one
of
the
reasons
that
source
and
type
are
actually
required
in
the
cloud
event.
Spec
right,
because
you
know
from
my
personal
experience.
Those
are
always
those
are
just
fundamental
things
that
are
always
interesting
in
in
in
the
context
of
consuming
events
and
understanding
where
events
are
coming
from
and
what
they
are.
J
So
I
I
I
and
I
appreciate
the
you
know,
making
sure
that
we're
focused
on
the
use
cases,
but
but
it
you
know,
there's
a
balance
of
like
going
completely
generic
right
and
being
completely
agnostic
of
use,
cases
versus
having
opinions
and
people
understanding
what
it
should
be
used
for,
and
you
know
from
my
experience,
source
and
type
are,
you
know,
part
and
parcel
of
of
consuming
events
in
general.
A
A
Oh
okay,
I'm
still
struggling
with
with
what
your
concern
is
meaning.
Are
you
worried
that
if
we
make
this
required
for
a
manager
that
it's
too
big
of
a
burden
for
them
to.
K
Support,
big,
isn't
the
concern
it.
It
may
be
useless.
K
That
or
their
entire
ecosystem,
the
people
that
would
be
interested
in
subscribing
don't
care
and
would
never
use
it.
I
think
just
that.
I
think
that
the
point
made
before
that
sometimes
opinions
are
important
to
have
completely
agreed,
and-
and
this
may
be
a
case
where
I'm
I'm
going
for
the
generic
too
easily-
that
that
is
a
failure
mode.
For
me.
H
Well,
there's
a
there's
a
generic
time,
so
the
generic
source
of
events.
Arguably
it
has
zero
scoping
and
that's
the
wall
clock
and
still,
if
you're
subscribing
to
a
particular
wall,
clock,
let's
say
the
utc
clock,
you
would
probably
still
get
a
source
get
it
get
it
get
a
source
to
just
disambiguate
that
wall
clock
from
any
other
part
of
the
system.
H
So
I
think
the
I
think
there
is
some
there's
always
some
level
of
scoping
in
your
events
and
this
the
scoping
is
expressed
in
the
events
per
se
through
the
source
and
then
it's
optional
for
the
subscription
manager
to
be
told
to
source
and
that's
why
we
make
the
field
optional,
but
I
think
the
subscription
manager
always
has
to
deal
with
with
the
source
information.
I
don't
think
that
exists.
I
don't
think
the
the
zeros.
I
don't
think,
there's
there's
there.
There
are
use
cases
outside.
H
Maybe
the
utc
wall
clock
that
are
that
can
do
completely
without
scoping.
S
Yeah
so
I'll,
I
always
got
to
ask
for
an
example
from
eric,
but
the
the
the
what
cummins
is
saying.
Let
me
let
me
give
you
an
example
from
the
enterprise
world,
enterprise
developers
are
lazy,
bastards,
and
so
the
notion
of
I
just
want
a
fire
hose
aggregator
that
some
other
team
controls,
and
so
I
I
in
essence,
have
no
other
actual
source
other
than
the
fire
hose
aggregator
right
and
then
I'm
gonna
pick
apart,
just
whatever
out
of
that
fire
hose
that
it
gives
me
or
I
have
some
other.
S
You
know
whether
it's
a
config
value
or
some
other
filter.
That
is
all
I
care
about,
and
I
communicate
that
in
whatever
custom
way
it
is
is
going
to
be
how
people
developers
like
that
actually
use
the
system,
because
that's
actually
how
they
use
a
lot
of
these
systems
today,
in
whatever
custom
configs
that
exist.
S
But
from
our
standpoint
that's
that's
a
degenerate
case
that,
like
making
making
source
in
this
particular
thread
optional
like
that,
doesn't
help
at
all
right.
If
people
are
going
to
willfully
use
or
you
know,
degenerate
their
use
cases,
we're
there's
nothing.
We
can
do
to
mandate
against
that
anyway,
and
letting
you
know
letting
providers
or
producers
off
the
hook
or
the
aggregator
off
the
hook
to
not
support
source
like
that
doesn't
seem
to
buy
anything
in
that
particular
case.
A
So
let
me
rephrase
them.
Let
me
echo
back
what
I
think.
I'm
hearing
you
say
so,
let's
say
someone
comes
up
with
a
use
case
that
says:
hey.
I
have
an
aggregator,
it's
going
to
get
events
from
a
whole
bunch
of
different
event.
Producers
and
all
this
aggregator
wants
to
do
is
be
a
funnel
for
it,
so
anybody
can
subscribe
to
that
aggregator
and
they're
just
going
to
get
all
events.
The
aggravator
is
going
to
be
really
really
dumb.
A
It's
not
going
to
do
any
filtering,
it's
not
going
to
do
anything
except
get
an
event
and
then
spit
it
back
out.
Okay,
that's
a
proxy
more
than
anything
else,
and
I
think
what
I
hear
eric
saying
is
that's
a
valid
use
case
and
therefore
it's
also.
It
would
be
invalid
to
force
that
aggregator
to
do
any
kind
of
filtering,
including
on
source,
but
then
I
think
john
you're
saying
is
nope.
It's
not
too
much.
S
Right
yeah,
so
in
that
case,
what
what
do
people
do
today?
They
basically
they
basically
just
put
a
dummy
value
where
the
source
is
the
aggregator
right
as
a
new.
I
guess
clemens,
you
would
call
it
a
scope
that
that
it's
just
its
own
scope
right
and
so
the
fact
that
it's
a
complete
mess
and
has
you
know
everything
in
the
kitchen
sink
in
it?
They
don't
like
they
don't
really
care
because
they're
gonna,
peel
off
or
filter
or
whatever
they're
gonna
do
to
that
fire
hose.
S
Right
and
that's
what
I'm
saying
it's
a
degenerate
case,
so
we're
gonna
if
we're
if
we're
right
and
and
like
I
like
a
bunch
of
enterprise
developers
like
I
can
totally
picture
hundreds
of
them
that
this
that's
exactly
how
they
think
they
don't
care,
they're,
not
going
to
put
it
in
unless
they're
forced
to
right.
So
it's
a
it's
a
willful
choice
and
it's
a
degenerate
choice,
but
it's
a
choice
that
people
in
practice
actually
make
regularly
right,
but
so
so
they
do
that
like.
Okay,
that's
their
problem,
but
why
that
particular
degenerate
use
case.
S
In
my
opinion,
shouldn't
shouldn't
affect
us
as
having
a
a
preference,
a
bias,
a
an
opinion
that
that's
actually
not
a
good
practice.
A
S
A
S
The
degenerate
use
case,
I'm
saying,
is
absolutely
a
bad
practice.
I'm
just
saying
like
we
have
to
be
like
we.
If
we're
going
to
take
an
opinionated
stand,
people
are
going
to
do
bad,
broken
silly
things,
no
matter
what
we
require.
S
S
So
it's
it's
it's
all.
It
ends
up
being
ad
hoc
and
then
ops
pushes
back
later
like.
Why
are
you
eating
all
this
data
and
they
go?
Oh
you
mean
I
can
filter
and
you
go
through
this
thing
and
it
takes
two
years
to
get
the
system
cleaned
up
right.
That's
that
that's
the
the
shortest
laziest
path
to
success,
so
that
they
can
claim
victory
and
move
on
to
their
next
their
next
ticket.
S
A
I
apologize
for
belaboring
this
point,
but
maybe
I'm
thinking
about
this
completely
wrong,
because
I
I
wasn't
thinking
of
this
use
case
as
being
degenerate,
bad
or
anything
like
that.
Rather
it's
a
valid
use
case
in
the
sense
that
this
aggregator
wants
all
these
events
from
all
these
event,
producers
and
they
want
to
allow
people
to
subscribe,
to
get
the
flood
and
what
they
do
with
it
down
the
line
is
up
to
them
and
in
that
particular
model
I
it
it.
A
A
S
S
Well,
so
that
that
now
we're
now
we're
getting
to
ownership
and
and
who's
who
right
like,
I
can
tell
you
in
in
in
the
in
the
in
the
the
big
enterprise
that
I
have
recent
scars
with,
like
that's
literally
how
people
thought
right,
they
didn't
they.
They
they
explicitly
didn't
want
to
like
if
they
took
this
fire
hose
example.
Where
they're
just
saying
hey
we're,
you
know
we're
some
kind
of
operational
or
security
system,
and
we
just
want
to
see
all
the
events
we're
going
to
do.
S
You
know
some
kind
of
analysis
on
it,
like
they're,
not
going
to
they're
not
going
to
filter
on
that
anyway,
right,
they're,
they're,
not
they're,
they're,
just
going
to
say,
hey
whatever
comes
in
we're
going
to
ignore
things
like
those
source
fields,
except
for
in
our
actual
analysis
right,
so
they're
doing
their
own
downstream
filtering
or
whatever
you
want
to
call
it
like,
and
that's
totally
fine
right
that.
But
that's
what
I'm
saying
going
back
to.
S
A
K
Anyway,
it
was
an
interesting
discussion.
I
definitely
didn't
mean
the
the
degenerate
case.
I
think
there
are
some
valid
use
cases,
but
I
I
I
I
worry
about
throwing
the
baby
out
with
the
bathwater.
If
we
disallow
the
the
degenerate
anyway,
I
do
have
to
drop,
though.
Okay,
thank
you
for
the
discussion.
H
I
H
I
feel
that
same
pain,
and
I
and
I
completely-
can
follow
it
and
then
also
have
the
including
the
the
enterprise
developers
are.
What
did
you
say,
lazy,
bastards.
H
And
that
constraint
is
one
where
I
would
say:
that's
an
implementation
policy
decision
that
we
should
enable
and
make
possible,
and
any
sane
implementation
will
probably
put
put
some
some
lid
on
that,
but
the
proxy
case,
where
you
really
want
to
have
the
ability
to
go
and
and
pull
through
a
fire
hose
for
purposes
of
replication.
H
It
is
not
an
invalid
one.
So
if
I,
if
I
have
this,
if
I'm
using
the
subscription
mechanism
to
say
I
want
to
have
a
replica
of
this
event
store
somewhere
else
and
the
way
and
and
by
creating
a
subscription,
that's
how
I
establish
that
that
relationship.
H
Then
I
actually
don't
care
about
the
sources
and
the
the
the
types
at
all,
but
I
simply
just
want
to
go
and
set
up
a
relationship
between
two
to
two
parts.
So
there
the
subscription
manager
is
the
scope
of
that.
Is
you
know,
implicitly
everything?
That's
that's!
That's
in
that
store,
so
it
might
not
even
care
about
the
the
source
input
in,
in
particular,.
S
Right
for
sorry
to
jump
in,
but
in
those
kind
of
cases,
for
the
legitimate
case
right,
I
was
trying
to
support
eric
in
the
degenerate
side,
but
on
the
for
the
for
the
valid
side
right.
If,
if
we're
going
to
say
that,
then
to
me,
what
that,
what
that
says
is
what
what
is
a
valid
thing
to
put
in
the
source
that
actually
ex
makes
explicit
this
view
of
no,
no,
I
I
literally
want
the
fire
hose
on
purpose
for
exactly
the
like
you're,
like
you're,
saying
the
replication
use
case,
for
example,.
A
H
Then
it's
really
up
to
the
subscription
manager
which
what
what
what
what
the
subscription
manager
gives
you
like,
you're,
no
longer
being
specific
in
the
subscription.
And
then
you
are
effectively
in
a
world
where
you
have
a
private
relationship
between
the
the
subscriber
and
the
subscription
manager
to
kind
of
sort
out.
What
what
how
the
relationship
of
that
subscription
to
the
sources
is.
S
Okay,
so
so
hold
on,
because
now
we're
talking
about
that's
that
goes
under
optional
for
client
right,
but
that,
yes,
I
worry
like
one
of
my
one
of
my
checks-
is
always
being
explicit
versus
implicit
behavior
right
and
if
we're,
if,
if
we're
saying
this,
is
a
non-trivial
or
use
case
right
that
people
explicitly
want
to
be
able
to
do,
it
seems
it
seems
like
a
better
thing
to
actually
make
that
explicit
as
opposed
to
a
degenerate.
S
A
H
So
that
might
be
there
might,
we
might
have
a
construct
that
is
the
anonymous
source
like
there's
a
and
they're
again
drawing
on
some
prior
art.
There
is
a
constructed,
mqp
called
the
anonymous
terminus
where
you
are
explicitly
saying.
H
H
That's
inside
of
it
and
I'm
just
allowing
you
to
have
a
place
in
my
broker
in
the
case
of
aqp,
where
you
can
go
and
send
stuff
to,
and
I'm
changing
the
the
I'm
making
exceptions
for
for
how
we're
going
to
do
addressing
in
this
case,
because
it's
really
for
the
proxy
case
and
that's
really
for
if
you're,
building,
mkp
routers,
for
instance.
H
That's
where
the
anonymous
term
is
kind
of
kind
of
comes
into
play,
and
I
can
see
that
we
explicitly
say
there
isn't
a
concept
of
an
anonymous
source,
which
means
there
is
a
special
case,
uri
of
sorts
or
some
some
expression
which
says
I
am
subscribing
and
explicitly
say
that
I'm
really
making
a
proxy
fire
hose
subscription
year
for
everything
that
the
subscription
manager
has
in
scope.
A
So
but
then
I
don't
think
that's
what
eric
is
focusing
on.
Okay,
so
john,
I
agree
with
you
that
we
should
have
a
discussion
about
how
does
someone
indicate?
I
want
everything
right,
whether
it's
absence
of
source
or
source
with
an
asterisk
or
source,
with
a
well-defined
url.
We
can
have
that
discussion,
but
I
don't
think
that's
what
eric
was
focused
on.
Okay.
So,
let's
assume
for
a
minute.
You
have
a
scenario
where
there
is
this:
aggregator
fire
hose
proxy
thingy,
okay
and
someone
can
subscribe
to
it
with
whatever
syntax
that
says.
A
Then,
if
this
subscription
manager
says
they
are
compliant
with
our
specification,
it
is
then
valid
for
someone
to
come
along
as
a
subscriber
to
say
that's
great,
but
you
know
what
I
don't
want
it
all.
I
want
to
subscribe
to
that
manager,
but
I'm
going
to
put
a
source
in
my
subscription
request
and
I'm
going
to
say,
github.com
or
something
like
that.
A
Okay,
we've
now
placed
a
burden
on
this
proxy
to
filter
events
coming
through
its
system
to
to
just
github.com,
even
though
he,
even
though
he
when
that
code
is
written,
it
may
have
been
written
with
the
assumption.
It's
only
going
to
do
fire
hose
and
everything
you
know,
everything's
going
to
go
through
it
and
everything's
going
to
go
to
every
subscriber.
A
S
A
If,
if
we
choose
to
make
this
optional,
then
yes,
the
discovery
spec
needs
to
have
a
flag
in
there.
That
says
for
this
subscriber
that
you're
going
to
subscribe
to
they,
they
either
support
it
or
they
don't
and
if
they,
if
they
say
they
don't
support
it
and
someone
subscribes
and
they
do
specify
a
source.
Yes,
I
expect
to
get
an
error
back
saying.
Sorry,
you
you
asked
for
something
I
can't
do
and
keep
in
mind.
I'm
not
saying
whether
this
should
be
optional
required.
I'm
just
trying
to
play
devil's
advocate
with
eric's
position.
A
S
A
A
And
I
think
I
think,
there's
two
different
levels
of
interoperability:
okay,
there's
internal
ability
from
a
more
of
a
syntactical
perspective
right,
do
people
understand
and
we
have
consistency
on
what
it
means
for
these
values
to
appear
in
there
and
how
they're
going
to
be
used
and
how
people
should
use
them
and
stuff
like
that.
I
think
I
think
we're
all
on
the
same
page
there.
A
Okay,
then
there's
the
different
level,
then
the
other
level
in
our
ability,
which
is,
does
everybody
support
what
they
need
to
support
so
that
it
actually
becomes
useful,
and
this
goes
back
to.
I
think
what
clemens
and
I
talked
about
in
the
past.
A
Is
you
know
in
the
ws
star
space
sure
we
had
interoperability
but
from
a
spec
perspective,
but
we
had
zero
in
our
ability
in
reality,
when
it
comes
to
the
security
specs,
because
everybody
implemented
their
own
specification
and
this
and
their
and
the
ws
security
specs
said,
choose
whatever
dialect,
you
want
in
essence,
and
and
and
everybody
chose
their
own,
so
you
have
zero
inaudibility
in
real
world.
That's
right!.
A
A
Right
so
I
I
don't
know
the
answer,
but,
to
be
honest
with
you,
my
gut
reaction
is
that
making
this
optional
is
not
reintroducing
that
problem,
because
I
I
actually
do
think
for
some
people.
It
may
be
a
a
too
high
of
a
bar
to
say:
hey.
S
S
My
gut
says
they
need
to
be
required,
but
like
with
content
negotiation,
if,
if
I
don't
support
that
as
one
of
these
aggregators,
then
when
you
make
the
subscription
attempt,
I
should
respond
with
an
error
saying
you
know
sorry,
I
don't
support
that
right
so
that
it's
explicit
the
whole
way
through
and
there's
an
actual.
You
know
error
response
or
whatever
to
to
make
that
clear
rather
than
having
it
just
well,
you
know
I'm
gonna
send
this
subscription
hope
it
works.
Have.
A
S
No
well,
in
that
sense,
I'm
saying
if
we
make
it
required
and
explicit
right,
we
can
cover
those
cases
and
great,
so
it's
required
and
the
but
the
the
the
the
the
interoperability
spec
with
the
aggregator
still
says:
hey
it's
required,
but
it's
it's
for
me
to
be
able
to
say
this
is
how
far
I
support
right.
So
if
we
have
various
levels
of
filters
or
sophistication
or
whatever
it
may
not
be
just
binary
on
or
off,
if
there
are
great
people
may
choose
to
do
different
levels
of
it
or
something
yeah.
A
See,
that's
that's!
That's
where
I
that's
where
I
have
to
push
back,
because
I
don't
like
the
idea
of
discovery
through
errors
right.
So
if,
if
you're,
if
the
spec
says
you
shall
support
this,
then
I
think
it'd
be.
I
think
it's
invalid
from
a
spec
perspective
for
someone
to
come
back
and
say
I
recognized
it,
but
I'm
not
going
to
do
it
and
therefore
I'm
going
to
error.
A
A
I
A
S
S
Right
so
so
in
my
in
in
my
in
my
thing,
because
of
my
my
my
fear
of
implicitness
right,
I
would
say
it
needs
to
support
source
filtering
on
an
exact.
You
know
whatever
that
prefix
pattern
or
uri
pattern,
whatever
whatever
that
level,
and
we
should
make
that
level
be
be
realistic,
but
it
should
be,
it
should
be
required.
S
S
To
the
w
star
problem
right,
if
the
degenerate
case
is
is
if
there
is
no
bar
other
than
here's,
the
fire
hose
people
will
will
will
will
will
sink
to
the
common
denominator.
G
H
H
H
H
But
what
we're
saying
here
is
that
it's
required
for
the
manager
to
understand
the
notion
of
source,
which
means
we're
talking
about
here.
It
is,
if
you
give
it
a
constraint,
then
the
the
manager
also
ought
to
respect
it,
which
is
which
is
for
constraining,
and
I
don't
think
we're
saying
we're
saying
that
you
can
that
you
can
always
get
an
unconstrained
feed
from
a
subscription
manager
like
like.
H
A
I
I
think
I
think
that
I
think
the
manager
needs
to.
I
think
the
manager
needs
to
understand
it.
Okay,
so
require
for
the
manager
is
what
you're
saying
yeah.
H
A
Yeah
yeah,
I
I
agree
with
you
that
I
think
it
should
be
allowed
to
say:
hey
the
source
string
you
gave
me
is
invalid,
but
it
has.
There
has
to
be
at
least
some
valid
string
that
it
would
accept.
Yes,
okay,
okay,
so
okay,
so
I
think
as
I
and
why
don't
we
do
this?
Why
don't
we
keep
it
as
required
for
now
and
we
can
continue
the
discussion
through
issues
or
something
else
or
just
or
the
next
time
at
least
now
I
feel
like.
I
understand,
eric's
concern
and
use
cases
better.
A
At
least
I
think
I
do,
but
I
think
we
need
to
get
more
feedback,
because
I
have
a
very
strong
suspicion
suspicion
that
remy
may
push
back
on
this,
because
I
think
he's
doing
the
exact
degenerate
case
that
we're
talking
about
here.
A
But
let's,
let's
hold
off
now,
as
we
were
talking,
though
it
dawned
on
me
in
the
case
of
github,
the
github
may
actually
have
it
be,
have
source
be
required
field
right,
it's
going
to
need
to
know
which
github
repo
you
want
events
from,
and
I
think
this
may
go
directly
to
what
you
were
saying.
Clemens
about
being
able
to
error
on
bad
strings
in
there,
I'm
assuming
it's
valid
for
the
substitution
manager,
error
saying
source
is
actually
required,
even
though
the
spec
allows
it
to
be
optional.
A
H
Trial
and
error
we
we
could,
since
we
have
a
since
we
have
a
metadata.
We
have
a
metadata
service
that
describes
the
subscription
managers,
so
we
can
probably
put
a
flag
there.
A
I
know
we
can
I'm
just
wondering
whether
we
should
because,
conceptually,
I
could
say,
hey,
that's
a
neat
idea,
but
at
the
same
time
I
also
don't
want
to
bloat
our
discovery.
Spec
the
source.
A
H
I'm
not
sure
that
we
need
to
have
that
expressed
dynamically,
because
I
mean
you
because
you
need
to
get
the
value
from
somewhere.
It's
not
that
you
show
up
and
and-
and
I
think
that's
context
that
you
that
you
need
to
have
like
you're,
not
gonna,
you're,
not
gonna,
pro
you're,
not
gonna,
provide
it
or
not,
provided
based
on
some
metadata
discovery
or
or
or
some
some
dynamic
value
that
you're
getting
back.
Okay.
Does
that
happen
to
compile
that
problem.
S
Well,
if
we're
gonna,
so
that
goes
back
to
my
thing
to
just
make
it
explicit
right.
So
if
we,
if
we
change
it
to,
if
the
manager's
side
is
required-
and
you
say
well,
the
client
side
is
required,
but
you
can
put
the
star
or
whatever
the
the
magic
incantation
for
give
me
everything
or
whatever
I'm
allowed
to
see
or
whatever
that
is
written.
S
As
then,
it's
explicit
on
both
sides
and
you
don't
have
any
negotiation
or
or
anything
you
just
have
the
I
support
that
or
I
don't
or
you
know
it's
bad
badly
formed
or
whatever.
A
A
A
H
Yeah,
what
I
meant
was
we
had
this.
I
yeah,
I
think
that's
that's
the
thought
that
I
expressed
earlier
with
having
a
special
catch-all
or
anonymous
source.
H
E
A
Okay,
tell
you
what
I
think:
okay,
let's
let's
do
this,
let's,
let's,
let's,
let's
pick
up
next
week
on
whether
it's
optional
versus
required
with
it
with
a
catch-all
string
but
for
right
now
we're
going
to
keep
it
as
required
until
we
hear
more
use
cases
actually
next
week,
okay,
I
would
like
at
least
a
three
minute
break
before
the
my
next
phone
call
at
the
top
of
the
hour
either.
A
A
We'll
be
back
here
again
next
week,
don't
forget
actually
what
I
was
going
to
do
is
I
was
going
to
take
this
example
and
rework
it
based
upon
the
decisions
we
made
today,
because
I
think
a
lot
of
things
actually
drop
by
the
wayside
and
relative
to
this
example.
We
may
not
need
the
full
time,
but
I
also
don't
want
to
assume
that
this
use
case
that
I
put
forward
is
the
only
one
we
want
to
discuss
so
I'll.
A
Try
to
before
the
end
of
the
week
revamp
this
thing
and
then
maybe
put
it
out
there
for
us
to
society
through
slack
or
email,
whether
we
want
to
continue
the
three
hour
discussion
or
whether
this
is
it.
I
I
have
the
sense
that
there's
more
to
discuss
here.
I
just
don't
know
what
they
are
right
now,
but
I'd
love
to
hear
your
guys
feedback
in
the
last
minute
or
so.
Do
you
guys
feel
like
we
have
more
to
discuss.
D
B
A
Okay,
well
tell
you
what
little
assumed
we're
gonna
go
three
hours
again
next
week
and
if,
if
for
some
reason
we
end
up
stopping
early,
that's
fine!
You
know
we
can
stop
after
five
minutes
and
for
the
first
hour
then
jump
back
on
for
the
second
hour
and
not
even
talk
for
the
third
hour
and
then
we'll
we'll
cancel
the
three
hours
going
forward.
A
Okay,
anyway,
thank
you
all
for
joining
for
the
three
hours.
I
personally,
I
thought
this
was
great.
I
love
these
brainstorming
sessions
and
I
do
think
we
ended
up
at
a
much
better
spot
yeah.
So
do
I
and
I'll
I'll
take
the
action
to
start
writing
up
some
of
this
stuff
either
by
just
updating
this
document
or
actually
through
pr's
and
stuff,
we'll
see
how
I
feel,
but
I
do
think
we
made
forward
progress
all
right.