►
From YouTube: CNCF Serverless WG Meeting - 2019-02-21
Description
Join us for Kubernetes Forums Seoul, Sydney, Bengaluru and Delhi - learn more at kubecon.io
Don't miss KubeCon + CloudNativeCon 2020 events in Amsterdam March 30 - April 2, Shanghai July 28-30 and Boston November 17-20! Learn more at kubecon.io. The conference features presentations from developers and end users of Kubernetes, Prometheus, Envoy, and all of the other CNCF-hosted projects
A
A
A
All
right
any
questions
about
the
SDK
work:
okay,
now
Clem
open
up
a
prayer
request
related
to
the
SDK
doc
and
I'll
get
to
that
later.
But,
as
I
mentioned,
the
warning
to
you
guys
would
be
look
at
that.
That's
pretty
soon
all
right,
Scott's!
Next
demo,
we
did
not
have
a
call
us
because
there
was
no
update,
but
is
there
anything
you'd
like
to
mention.
A
Anybody
have
any
questions
or
comments
about
that
gun.
Just
quick
opportunity:
okay
kuqali,
you
might
think
we
may
have
had
a
planning
session
since
last
time.
I
don't
have
anything
radically
different.
The
notes
are
actually
in
this
stock.
If
you
guys
want
to
take
a
look
at
what
we're
doing
in
terms
of
how
things
are
shaping
up
just
a
quick
refresher,
I
came
here
for
sure
bud
mentions
last
time,
but
we
will
have
a
cloud
events
intro
and
a
cloud
events
deep
dive
and
we're
looking
to
have
180
minute
long
service
working
group
session.
A
Where
we'll
talk
a
little
bit
about
the
state
of
the
industry
relative
to
service,
followed
by
hopefully
more
of
a
birds
of
a
feather
type
of
discussion
where
we
try
to
get
the
community
involved,
we
are
still
trying
to
figure
out
how
that
session
relates
to
the
bigger
service
days.
Okay
I
wrote
that
term
they're
using
for
it
that
they're
thinking
about
doing
at
coop
Connie,
you
may
overlap
with
it
swim
in
the
canceling
ARS
integrate
into
there
or
may
keep
it.
We
don't
know
yet,
but
that's
still
something
that's
up
for
discussion
just
so.
A
You
guys
know
is
there
more
information
on
there
that
I
hadn't
heard
of
that?
No,
unfortunately,
they
haven't.
They
have
a
Google
Doc
out
there.
That
I,
don't
think,
has
been
updated
in
quite
some
time.
I
did
reach
out
to
Chris
and
check
to
find
out
more
information,
but
he
hasn't
gotten
back
to
the
yet.
So
as
soon
as
I
get
more
information
we'll.
Let
you
guys
know
thanks
yep
right
any
questions
on
that
all.
C
A
Koukin
China,
just
as
a
reminder,
I
believe
the
CFP
for
that
is
closing
tomorrow.
I
believe,
just
for
you
guys,
reference
I
will
be
asking
for
an
intro
and
deep
dive,
35
minute
sessions
and
then
a
bigger
8
a
minute
one,
just
like
we're
doing
for
COO
Connie
you.
If,
for
some
reason
we
decide
not
to
use
them,
it's
very
easy
to
drop
them.
I
think
it's
hard
to
get
them
after
the
deadline
for
things
I'm
going
to
ask
for
them
and
then
always
cancel
we
need
to.
A
A
It
may
be
very
similar
to
what
we're
already
doing
in
the
EU,
so
we
should
really
use
a
lot
of
it,
so
mainly
the
the
biggest
unknown
for
me
is
who's
going
to
be
there
I'm
going
to
do
some
talking
so
be
thinking
about
that.
You
guys
get
a
chance.
Okay,
any
questions
on
that
all
right.
Looking
forward
to
PRS
I
struggled
a
little
trying
to
figure
out
the
right
order
here,
unfortunately,
I
don't
think
any
of
these
are
technically
ready
to
go
so
I
figure.
A
D
I
feel
like
I
feel,
like
everyone
knows
what
Clemens
and
I
think
I
think
they
know
where
we
stand
and
I
think
like
the
bigger
question
I
have
is
if
this
is
something
that
we
want
cause
like
if
it's
okay,
I
guess,
I
have
one
question:
if
anyone
hasn't
read
through
what's
there,
then
we
should
absolutely
like
summarize
it.
But
if
everyone
has
read
through
it,
then
that
seems
like
a
waste
of
time
to
just
like
rehash
it.
So
I
think
what
I
would
like
is.
D
Is
this
a
thing
that
people
want
and
if
so,
what
needs
to
change
to
actually
write
something
here
that
people
want
if
it's
not
something
that
people
went
like,
if
no
one
cares,
if
no
one
is
interested
in
making
it
possible
for
proprietary
aspects
to
like
lists
that
they
are
proud
of
it
compatible.
Then
great,
we
should
just
close
this
if
people
think
it
needs
changes
and
we
should
specify
what
those
changes
are
and
if
people
want
to
like
make
this
happen,
then
you
should
say
that.
B
E
B
E
D
D
It's
good
for
anyone
else,
who's
interested
in
using
that,
and
also
its
to
support
cloud
events
like
if
something
doesn't
have
broad
support
right
now
that
doesn't
mean
that
it
won't
I
also
I.
Also
don't
really
want
to
be
in
charge
of
saying,
like
you
are
large
enough.
I
just
want
to
say
if
everyone
wants
to
support
cloud
events-
and
you
have
a
right
like
in
your
all
proprietary,
then
like
here's,
how
they
do
it.
Here's
like
a
way.
Okay,
people
are
raising
their
hands,
so
people
in
chat
can
talk.
No,
that's.
A
A
A
Well,
okay,
I
need
to
me.
Let
me
state
Mike,
my
three,
my
three
options
as
I
see
it
one
is
close.
It
do
nothing
to
is
have
a
list
in
our
repo
someplace
of
known
bindings
that
we
just
don't
keep
in
our
repo
and
that
would
include
proprietary
ones,
and
then
the
third
option
is
what
you're
proposing,
which
is
a
lab
proprietary
ones
to
actually
live
in.
Our
repo
and
I
wanted
to
know
whether
those
are
the
three
options
or
whether
there's
more
choices.
We
need
to
consider
I.
D
A
B
F
Here,
I
think
that
it's
it's
probably
useful
to
consumers
of
the
spec
to
have
a
list
of
those
protocols
that
are
supported
whether
or
not
those
are
open
or
proprietary
protocols.
It
seems
like
we
would
be
taking
on
a
fair
bit
of
friction
and
overhead
if
those
protocols
and
their
mappings
were
placed
into
this
repo,
but
anyone
that
was
willing
to
produce
a
the
you
know
specification
of
the
mapping
and
then
link
to
it
would
would
then
be
able
to.
This
seems
what's
reasonable
to
me.
C
G
So
I
already
wrote
a
comment,
but
to
repeat
it:
I
think
for
interoperability,
that
people
should
go
and
somehow
also
submit
an
implementation.
They
don't
necessarily
have
to
implement
it
for
all
our
SDKs
or
so.
But
if
there's
at
least
one
implementation,
then
it
shows
that
is
really
interoperable
and
it
also
means
that
we
have
a
starting
point
to
actually
use
it.
So
personally,
I'm
actually
interested
in
having
a
cloud
events
binding
for
some
of
the
a
Tobias
stuff
like
SQL
and
SNS,
for
example.
That
would
be
something
that
I've
won't
find
valuable.
G
H
H
Because
the
reason
I'm
bringing
it
up
is
just
because
I
feel
like
again
without
a
TCK
or
anything
like
that,
we
can't
prevent
anyone
from
creating
any
any
spec
or
any
binding.
I
would
say
any
transport
for
for
what
we're
doing
here.
The
decision,
then,
is
just
like
where
we
want
to
host
it
right
and
if
you're
calling
it
like
a
support
or
whatever
certified
or
approved
blast
by
the
group
here,
and
if
it's
a
proprietary
one
like
I,
think
based
on
what
I've
heard
from
others
here
and
I
think
I
would
agree
like
again.
H
You
can
implement
that
and
that's
not
coming
out
of
the
working
group.
So
we
are
not
endorsing
it,
but
we
recognize
that
sure
you
are
implementing
this
back
end.
Click
on
this
link
go
there
figure
out
how
that
spec
actually
makes
sure
that
they
are
compliant
with
with
cloud
defense,
but
we
are
not
making
that
we're
not
guaranteeing
that
right.
It's
a
yet
another
respect
out
there
that
someone
implemented
based
on
what
we
produced
here,
and
we
just
can't
prevent
that
right.
It's
open
source
software.
They
can
read
this
back
just
like
happen
with
WebSockets.
H
H
A
D
C
A
D
That's
all
I
am
suggesting
that
we
should
do
whatever
it
is.
That
can
get
enough
support
from
the
group
to
let
people
who
are
not
part
of
the
group
and
who
have
proprietary
protocols
start
supporting
this.
But
if
the
best
that
we
can
do
is
get
links
in
the
repoed,
then
that's
what
I
think
we
should
do.
I
think
that
we
should
make
it
as
easy
as
possible
for
people
to
find
everything
so
I
think
keeping
things
in
a
folder
in
the
repos.
D
A
Okay,
however,
in
order
to
make
forward
progress,
we
need
to
decide
our
next
step
and
I'm
trying
to
figure
out
whether
the
next
step
is
to
say
the
current
proposed
on
the
table
is
just
links
or
do
we
want
to
go
as
far
as
to
say,
we've
talked
about
this
enough:
let's
do
a
vote
Lynx
versus
speck
in
our
repo
and
let
the
majority
went
or
is
there
another
option?
I'm.
J
D
D
A
I
forgot
about
that
piece:
okay,
yeah,
cuz,
I!
Don't
want
us
to
be
on
the
hook
to
update
someone
else's
spec
continually
and
if
they
don't,
if
they're,
not
responsive
to
issues
that
get
opened
up
against
our
repo,
then
that
out,
you
gave
us
of
saying:
okay
they're,
not
responding,
we're
gonna
kill
off
their
spec.
That's
fine!
Okay!
Thank
you!
A
Okay!
So
in
terms
of
moving
forward,
it
sounds
like
what
I
should
do
is
after
this
call
start
a
vote.
I
like
we
could
do
it
through
the
PR
itself,
where
people
can
vote
offline
if
they
need
to.
But
then
the
vote
closes
beginning
of
next
week's
call
and
the
choice
is
just
links
to
other
specs
from
our
repo
or
the
other
specs
themselves
living
in
a
proprietary
folder.
You
know
repo
have
that
right.
Rachel
yeah.
D
A
A
K
A
G
G
A
D
A
D
A
C
A
A
A
G
This
one
first
okay
yeah,
so
we
discussed
this
a
couple
of
times.
The
Eagle
is
that
we
have
a
minimum
support
of
the
event
size
so
that,
as
a
producer
I
know,
I
can
fire
off
an
event
and
that
basically,
everyone
who
follows
after
me
will
accept
it
most
likely
be
two
instead
two
shirt,
so
people
can
still
up
out.
If
they
have
to
yeah,
then
we
did
discuss
that
a
couple
times.
I
think
one
of
the
well
Clemens
made
a
comment
in
the
last
week.
That
is
basically
what
happened
and
I
responded
to.
E
E
So
I
am
agree
with
that.
The
size
limit
generally
but
I
think
it's
the
whole
normalization
by
adjacent
is
something
I
find
a
little
odd,
because
you
know
you
sent
events
and
the
event
has
64k.
The
publisher
puts
it
on
the
wire
in
a
certain
format,
with
a
certainty,
payload
and
either
fits
or
doesn't
and
and
ultimately,
if
there's
an
intermediary,
then
it's
a
meteor
or
choose
chooses
a
different
encoding.
E
It's
up
to
the
intermediary
to
make
sure
that
that
that
shit's
and
it
doesn't
fit
that
it
needs
to
go
and
report
that
out
in
some
way.
But
if
you
this
feels
like
this
feels
like
we're
doing
this
in
Jason
and
see
okay,
it's
kind
of
the
median
of
all
like
you
literally
meet
the
right
code.
No,
that
needs
the
measures
in
some
way
in
ways.
Yeah
the
the
events
in
Jason
you,
even
though
you
don't
even
care
about
Jason.
E
If
there
was
a
specification
now
4c
bore
anyone,
the
only
thing
you
would
do
the
Seaboard
and
then
re-encoded
syncope,
you
kind
of
would
have
to
weigh
that
the
the
event
in
in
Jason
to
make
sure
your
performance
with
this
section
so
I
find
this
whole.
This
whole
reference
to
Jason,
and
this
the
you
know,
trying
to
be
trying
to
you,
know,
give
her
a
relative
normative
size
of
the
event
in
Jason.
E
A
G
So
I
think
there's
two
points.
I
think
the
point
that
you
make
that
it
is
rather
complicated
to
go
over
Jason,
even
if
you
don't
use
it
I.
It
is
a
weak
point
of
this
proposal.
Alright,
before
we
discussed
a
little
bit
other
options,
I
can
still
redo
the
discussion.
I'd
like
another
option,
will
be
to
say:
okay,
D
D
cloud
event
can
have
up
to
50,
okay
first,
maybe
the
first
thing
is
it's
only
a
minimum
sporting
event
size.
So
there's
a
guarantee
that
you
have
to
accept
it.
G
Well,
if
you
just
don't
care,
you
can
always
send
higher
stuff
and
I
just
hope
that
it
is
being
accepted
by
everyone
who
comes
after
you.
You
only
really
have
to
do
it,
especially
as
an
intermediary.
If
you
want
to
be
sure
that
it
will
pass
on
and
the
same
as
a
producer,
so
I
think.
If
the
producer
does
this
once
and
then
basically
everyone
else
along
the
line
doesn't
have
to
do
it
anymore.
But
back
to
the
point
that
I
was
trying
to
make
about
Jason
is
too
complicated.
G
Another
option
would
be
to
say
we
define
the
limits
in
a
different
way,
saying
like
maybe
to
support
at
least
50
attributes.
Every
attribute
can
be
up
to
a
kilobyte
in
size,
measured
in
some
way,
and
then
the
data
or
a
world
can
be
up
to
that
size.
So
that
would
kind
of
make
the
definition
on
the
our
set
is
on
the
abstract
model
of
the
cloud
event
and
not
on
something
elseƶ
lized.
G
That
is
read
also
something
one
has
to
write
code
to
write
fine,
but
maybe
it
isn't
so
specific
I
picked
Jason
here,
because
basically
Jason's
support
is
poor.
That's
the
reason
why
I
picked
Jason,
but
we
can
still
go
and
try
to
do
something
else.
That's
my
first
point.
The
second
point
is
it's
not
necessary
that
everybody
has
to
do
it.
You
only
have
to
do
it
if
you
want
to
make
sure
that
this
will
be,
this
message
will
be
passed
on
along
the
way
by
everyone.
Otherwise
you
don't
have
to
okay,
hey.
A
A
Case
petha
and
Scott,
it's
got,
you
have
an
opinion
on
this.
One
I
use.
B
So
in
the
in
the
go,
SDK
actually
translate
the
cloud
event
into
an
intermediate
piece
and
it
would
be
actually
a
pretty
impossible
for
me
to
do
what
Clemens
is
asking
in
the
way
it
as
a
JSON.
If
I
don't
have
a
JSON
encoding
type,
so
it's
a
pointing
I,
also,
don't
know
what
the
transports
gonna
do
over
the
wire
exactly.
Why
send
it
the
raw
event.
A
B
B
G
Yet
that
is
sort
of
what
I'm
try:
I'm
eeen
yeah
I
butterfiy.
If
that
still
comes
down
to
how
you
represent
stuff
or
how
say
where
you
have
the
event
name
and
sorry,
the
attribute
name
and
then
the
attribute
value
and
football,
it
kind
of
depends
on
how
you
represent
it.
If
you
say
okay,
this
is
these
are
asking
characters
for
the
attribute
name?
Then
it
has
a
different
size.
Then,
if
these
are
you
have
16
characters
for
some,
so
it's
still
not
so
easy.
G
G
B
K
I'm
not
sure,
so
what
was
Clements
proposal?
Are
you
proposing
that
the
Visayas
are
you
proposing
I
mean
with
existing
Jason?
This
proposal
I
think
he's
fine.
You
know
because
from
that
from
the
you
know,
64kb
right
with
the
JSON
format
I
can
derive
as
a
even
consumer.
I
can
derive
say
what
is
a
you
know
size
of
the
message
and
then
I
know
my
own
particle
I
mean
particle
connecting
to
my
arm
event.
Consumer
system,
so
I
cannot
work
besides.
I
should
I
should
accept.
K
E
K
Then
how
do
you
know
accept
event?
So,
what's
the
city
for
K
be
represent?
Does
it
represent
the
rural
size,
the
size
of
the
wrong
message?
What
does
it
represent
us
the
size
of
the
message
encoding
in
some
other
format?
What
comes
across
the
wire
across
the
way,
so
you
mean
the
wire,
so
I
mean
no
matter
whether
it's
an
intermedia,
a
routing
system
or
gateway
or
the
even
even
consumer.
K
We
already
know
we
can
sum
total
size
is
64
KB.
Is
that
what
you
mean
yeah
the
size
is
the
buffer?
Okay,
then
could
produce
or
no
so
the
even
producer
has
know
all
the
different
particles
and
then
to
calculate
to
make
sure
the
events
the
size
of
the
raw
message
has
to
be.
You
know
about
what
size
right,
so
the
producer
does
not
know
what
kind
of
particle
in
along
the
way
will
be
used.
K
E
Every
messaging
messaging
product
in
existence
has
called
us
from
our
message
size
and
there
are
always
about
the
frame
size
and
an
HTP
is
to
say
and
and
and
if
you
use
buffered
HTP
there's
also
it's
also,
but
most
messaging
systems
have
some
limits.
Some
protocols
actually
tell
you
upfront,
she
was
the
maximum
price
frame
sizes
and
you
have
to
stay
under.
You
have
to
stay
under
that
trend,
size.
K
E
Just
sends
it
sends
the
data
to
its
first
Bob
and
and
if
the,
if
the
intermediary
get
really
coating
of
the
of
the
event
and
not
forward
that
event
as
it
is,
then
it
is
on
the
hook
to
make
sure
that
it
doesn't
exceed
the
limits
of
its
next
destination.
Because,
ultimately,
the
routing
is
all
hop,
hop,
hop
hop
where
it
gets
to
bigger.
And
if
you
even
immediately
choose
to
do
a
reading
coding,
it's
on
the
hook
to
make
sure
that
that
really
code
actually
works.
K
Intermedia
I
mean
altro
whatever
make
sure,
but
the
thing
is
sometimes
you
know
if
the
chains
are
particle
right,
you
know
unless
he
does
something
other
trick.
Oh
like
doing
compression
was
sometimes
it
just
becomes
larger
right
and
the
if
they
make
it
larger
than
the
event
you're
given
consumer
cannot
come
on.
I
know
it.
E
Yeah
that
would
be.
That
would
be
very
unfortunate,
but
that's
just
the
way.
It
is
if
you,
if
you
choosing,
if
you
choose
it
to
change
from
a
protocol,
you
take
it.
You
start
with
a
contact
profile
like
a
DDT
and
you're
choosing
a
more
protocol
that
has
more
bits
on
wire
like
HTTP.
Yes,
your
message
was
gonna
grow
and
that's
something
that
someone
who's
building
the
integration
for
this
will
have
to
go
and
live
with
and
deal
with
is
that
they
have
a
probe.
K
K
C
Sure
I
I
just
think
that
we
should
be
encouraging
people
to
send
that
small
payload
as
possible,
because
it's
more
efficient
in
just
on
the
corner
to
actual
data.
If
they
really
need
it,
you
know
we
need
to
set
the
right
tone
as
to
what
we
think
an
event
should
be.
It
doesn't
contain
a
ton
of
data
in
it.
I
agree,
yeah.
L
I
feel
this
is
a
really
important
point,
because
it
really
changes
the
perception
and
attitude
of
developers
who
use
mechanisms
like
this.
You
know,
often
in
organizations
when
you
come
up
with
something
that
that
looks
like
file
transfer
people
will
start
moving
large
files.
So
I
had
a
recently
situation
like
this,
where
it
was
intended
as
event,
and
somebody
was
thinking
passing
five
gigabyte
files
through
this.
So
having
having
the
sentiment
eventually,
small,
the
infrastructure
for
processing
should
be
small,
lean
and
fast
is,
is
something
that
I
feel
we
should
promote.
Thank
you.
A
A
I'll
open
up
an
issue
to
make
sure
we
least
have
that
discussion
later,
because
I've
heard
that
come
up
more
than
one
time
and
several
discussions,
I'm
going
to
be
a
good
thing
with
mentioned.
Okay,
so
my
hands
up,
it's
not
a
people,
not
a
whole
lot,
who
were
speaking
I,
wanted
just
hear
him
I
hit
that
on
this.
So
while
stops
original
goal
of
being
able
to
know
that
this
particular
events
will
always
fit
no
matter
how
many
times
that
gets
transformed
of
different
protocols
and
bindings
and
stuff
down
the
wire?
A
Well,
you
know
it
will
always
work
I.
It
does
feel
a
little
bit
odd
to
me
to
require
one
particular
piece
of
middleware
to
have
to
serialize
to
Jason
when
they
you
would
normally
not
touch
Jason
at
all.
It
just
feels
a
little
bit
odd
to
me
and
because,
ultimately,
what
really
matters
is
that
64k
on
the
wire
III,
don't
I
I'm
meeting
a
little
more
towards
Clements
view
on
this,
which
is
just
it's
the
center's
responsibility
to
make
sure
it
fits
under
64k.
A
If
it
doesn't,
then
they
need
to
tree
out
how
they're
going
to
deal
with
it,
but
asking
them
to
transform
it
to
Jason
when
they
don't
normally
care
about.
Jason
just
feels
a
little
bit
awkward
to
me,
even
though
I
do
appreciate.
There
is
no
goal
of
you
know
some
sort
of
standardization
across
all
the
protocols.
Anyway,
that's
where
my
head's
out
in
this
anybody
else
wanted
to
speak
up.
A
I
A
Okay,
so
that
case
Kristof
I
feel
like
I'm
in
the
same
position
we
were
in
the
previous
issue.
How
would
you
like
to
move
forward?
Would
you
like
to
have
more
discussions?
Would
you
like
to
have
a
vote
of
you
know
first
sentence
versus
entire
PR?
How
would
you
like
to
to
go
about
trying
to
resolve
this.
D
G
G
A
Well,
just
let
you
know,
since
this
is
your
PR,
you
get
to
decide
what
people
are
voting
yes
or
no
on,
and
so
it's
really
up
to
you,
but
it.
So
if
you
feel
strongly
that's
what's
in
there
is
they
propria
one
then
will
basically
do
basically
an
up
or
down
vote
on
the
PR
as
it
stands
and
Clemens
or
anybody
else
is
welcome
to
open
up
a
a
second
PR
if
week
is
named
before
a
different
polls.
A
All
but
well
do
we
could
deal
with
that
separately,
but
so
it's
kind
of
up
to
you
in
terms
of
how
you
want
this
PR
to
be
voted
on
it
but
dumb,
but
don't
feel
like
you
have
to
change
it.
If
you
don't
want
to,
you
could
say
nope
I
like
it
just
the
way
it
is.
Let's
vote
yeah
I,
get
that
point:
okay,
okay,
so
okay
C,
but
you
said
you
wanted
to
think
about
a
little
bit
more.
So
maybe
the
next
week's
call
well,
we
won't
go
into
a
broad
discussion.
A
You
just
let
us
know
how
you
want
us
to
move
forward
and
if
you
have
different
roles,
obviously
we
can
talk
about
that,
but
nothing
changes.
Then
you,
let
us
know
how
you
want
to
move
forward
on
this.
Is
that
fair,
yes,
sounds
good,
okay,
cool!
Thank
you
very
much.
Is
there
anybody
else
who
wants
to
bring
up
anything
related
to
this
before
we
move
forward.
A
Take
some
notes
on
that:
a
sec
Christophe
another
one
of
yours.
G
A
G
One
in
terms
moving
forward,
so
I
wasn't
I,
wasn't
100%
sure
if
I
should
open
this,
then
Jim
said
in
some
comments
that
he
will
definitely
want
this
I
open
it,
but
now
I
kind
of
feel
that
there
is
not
a
lot
of
people
interested
in
having
it.
So
in
terms
of
keeping
the
discussion
short
I
think
we
talked
about
it
a
couple
of
times.
G
It
will
be
of
interest
to
me
if
people
think
this
should
be
in
the
main
spec
or
if
the
sum
is
something
I'd
rather
go
into
the
next
tension,
because
that
would
also
be
fine
for
me.
So
basically,
the
issue
is
that
if
you
have
a
really
a
small
limit
and
I
agree
with
mark
that
we
and
the
others
that
we
should
have
a
small
element
and
people
shouldn't
put
all
the
stuff
in
there
and
instead
provide
a
pointer.
G
So
this
is
about
providing
a
pointer
to
the
data
instead
of
sending
it
along
with
the
event.
So
if
people
think
we
should
make
that
part
of
the
spec
as
a
first
level
concept-
and
this
is
a
proposal
for
it-
the
other
option
is
to
just
use
the
data
in
a
how
would
I
say
this
proprietary
little
provider,
but
in
a
way
that
you
just
make
up
and
the
consumer
has
to
figure
out
how
it
works
in
this
case,
maybe
the
SDK
can
help
you
and
resolve
the
data
for
you.
That's
the
idea.
C
C
A
In
essence,
the
idea
of
the
image
inside
that
bucket,
so
the
URL,
wasn't
they
SiC
or
the
reference.
Wasn't
a
single
entity
like
a
URL,
exactly
split
across
multiple
fields
and
the
and
the
thing
that
ran
through
my
mind
was
hey.
That's
exactly
we're
doing
here.
Sort
of
so
would
we
then
force
someone
to
have
to
construct
a
URL
when
they
already
had
the
information
in
there.
You
know
I
am
forced
to
jump
through
hoops
that
they
wouldn't
don't
really
have
to
do
when
because
they're
already
satisfying
this
requirement,
and
so
when
I
started.
A
Thinking
about
that,
that's
when
my
mind
started
thinking.
Well,
maybe,
as
Clemens
and
and
Mark
have
said,
let
that
be
sort
of
a
application-specific
mechanism
to
define
the
pointers
and
again
go
back
to
just
putting
guidance
in
the
primer.
That
says,
don't
send
large
data
just
include
pointers,
but
we're
not
going
to
tell
you
exactly
how,
because
you
may
have
more
than
one
pointer,
you
could
have
lots.
Different
ways
represent
pointer.
We
can't
know
in
advance
what
that's
going
to
be
yeah.
A
K
I
thinking
so
I
agree
with.
You
know
how
we
define
this
I.
Try
I
give
this
comment
before
how
we
define
different
the
information.
If
there's
a
large
size,
our
payload,
that
information
might
be
saved
in
different
places,
there
will
be
different
ways
to
represent
that
that
place.
So
I
myself,
I
do
not
know
how
either
there's
a
universal
consistent
with
one
way
to
take
all
the
different
different
ways
in
those
places,
but
I
still
like
on
the
idea
of
you
know.
K
We
need
something
in
the
identity
to
be
in
the
header,
because
it's
easier
now,
if,
if
he's
embedded
in
the
data-
and
also
there
could
be
a
case,
the
data
is
not
in
the
cloud
events.
Then
you
know
we
need
some
place
to
know.
Where
is
that
that
large
payload
be
stored
right
I'm,
just
wondering
whether
we
can?
K
If
we
can,
you
know
how
to
say
we
can
find
out
what
Hanna,
what
are
all
the
ways
those
information
could
be
saved,
and
then
we
define
different
types
and
then
and
then
for
if
each
type
how
we
represent
it,
and
this
will
be
easier
for
the
event
consumer.
On
the
event
producer,
because
so
I'm
not
sure
whether
every
you
know,
we
leave
it
up
to
every
arm
every
event
producer
to
divide
them.
K
How
could
the
even
consumer
know
how
to
interpret
where
I
mean
how
to
kind
of
save
an
consumer
know
on
what
is
the?
What
is
a
way?
That's
if
I'm,
to
find
on
the
reference
to
that
data,
maybe
a
dot
and
I
misunderstand
York!
No.
A
No
I
think
you
I,
know
I
think
you're
right
if
we
do
not
define
it
as
part
of
our
specification
and
then,
if
it's
a
placate,
if
the,
if
the
reference
is
application-specific,
then
yes,
every
receiver
would
have
to
know.
That's
the
sabbatical
applications
for
math
of
how
the
reference
is
is
stored
in
there
and
whether
it's
in
the
body
or
in
extension,
attributes
you
don't
know
you
you
just
have
to
have
knowledge
in
advance
of
where
the
information
is
your
right.
K
K
A
M
M
A
G
Mean
it
is
a
problem
that
I
know
I
have
because
in
our
events
we
include
changes,
and
sometimes
they
can
be
small.
Sometimes
they
can
be
bigger,
so
I
just
know,
and
this
is
what
I
actually
I
do
today
is
that
if
the
changes
become
too
big
and
there
are
externally
storm
and
they
are
not
included
in
the
event,
so
I
have
this
mechanist
but
I,
don't
know
how
universal
it
is
like.
G
If
everyone
else
basically
does
not
have
this
problem
and
everybody,
you
know,
the
everybody
else
has
events
where
they
say:
okay,
I
just
have
five
kilobytes
and
I.
Don't
need
this
then
I
sort
of
agree
that
it
it's
not
a
valuable
addition
Tweedy
spec,
because
it
complicates
maybe
things
for
everyone
else.
So
then
it
makes
sense
to
have
it
as
an
extension
maybe
and
then
I
would
make
if
it
is
an
extension.
A
N
So
for
us,
it's
a
frequent
pattern
to
have
this
ref,
especially
for
this
third
reason
mentioned
here
in
this
list.
So
I
don't
know
I.
We
already
have
something
like
this.
Really
in
our
events,
it's
not
standardized
might
be
interesting.
I,
don't
know
it
could
also
be
refined
with
an
extension
would
be
the
main
concerns
against
it.
E
Yeah,
so
first
you
need
to
be
able
to
resolve
this
and
to
be
able
to
resolve
it.
You
need
to
know
what
you're
looking
at
and
so
just
having
just
having
that
woman
actually
and
not
having
it
decorated
with
you
know,
information
about
size,
and
then
you
have
to
worry
essentially
about
authentication
against
that
source
and
then
the
the
reference
may
actually
be
in
a
networking
scope
that
is
known
to
the
producer.
But
then
the
event
gets
forward
and
then
the
data
is
not
there,
because
it's
either
or
it's
either.