►
From YouTube: CNCF Serverless WG - 2018-06-28
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
Okay,
not
yet
okay,
Booker
circle
back
around
all
right.
First
on
the
agenda
community
time
is
there
anybody
from
the
broader
community
who
isn't
usually
part
of
this
call
who'd
like
to
bring
up
a
topic
for
discussion
or
ask
question
by
feedback
anything
almost
lines,
I
think
everybody's,
our
regular.
Unfortunately,
all
right,
not
hearing
anything
we'll
keep
moving
forward
next
week
is
the
fourth
of
July
week
or
holiday
in
the
in
the
states.
I
believe
I'm
just
double
check
with
the
other
week.
The
fourth
of
July
is
Wednesday.
A
Now,
sometimes
people
do
take
vacation
before
or
after
that
date.
So
I'm
wondering
whether
we're
gonna
have
enough
people
on
the
call
next
week
or
that
you're
going
to
make
I'm
gonna
be
on
vacation
and
we
should
skip
the
next
week's
call.
So
let
me
ask
this
question:
who
will
be
on
the
call
next
week,
I.
C
D
D
A
Okay
aside
from
Adobe
and
I
and
Google.
A
It's
just
like
a
lot
of
turnover.
People
might
be
able
to
make
it
I'm
inclined
to
to
keep
the
call
just
because
I
know
that
we
tend
to
be
us-centric
on
things,
but
in
this
particular
case
it
sounds
like
we
may
actually
have
enough
us-based
folks
and
it's
obviously
the
non-us
base.
Folks
will
probably
be
here
I'm
inclined
to
say
we
keep
the
call.
What
do
people
think.
F
H
A
Lucky
you,
yes,
all
right,
I,
don't
know
what
do
people
think
people,
okay
with
keeping
the
call
I
know
it's
not
ideal
for
some
of
the
u.s.
folks,
but
hopefully,
if
there's
something
that
you'd
like
us
to
skip,
you
just
mention
it
and
we'll
try
to
skip
that
particular
topic.
A
People
get
with
that:
okay
I'm,
not
here
any
objection,
so
we're
gonna,
keep
the
call,
sorry
guys.
Alright.
Next
on
the
agenda
new
logo
Austin,
we
gave
you
a
week
to
create
a
PR,
and
you
said:
you've
not
done
it
yet
now.
Does
that
mean
that
it's
still
something
you
want
us
to
hold
off
on
or
should
we
assume
that
we
should
go
with
it.
E
It's
up
to
all
of
you,
I
would
love
to
do
this.
I
just
haven't
gotten
to
it
this
past
week,
but
at
some
point
you
have
to
call
me
out
as
a
blocker
and
just
move
forward.
I
love
one
one
additional
week
to
give
this
a
shot
and
if
I,
if
I
don't
deliver,
then
you
should
move
on
without
me
and
that'll
just
be
the
way
it
is.
Okay,.
A
E
You
know
this
personal
opinion.
It
looks
a
little
unmodern
and
I
think
that
there,
with
a
few
tweaks,
especially
around
the
font,
it
could
look,
maybe
a
bit
a
bit
more
modern,
a
bit
more
fresh,
so
I'd
like
to
try
that
and
I
gave
myself
one
week
to
deliver
and
then
I
did
deliver
accepted
swamped
so
I'm
asking
for
one
more
week
and
if
anyone
else
feels
like
they
want
to
contribute
some
other
some
other
ideas.
I
think
we
should
absolutely
welcome
that.
E
A
So,
let's
do
this,
let's
give
you
one
more
week
and
if
somebody
wants
to
join
in
the
redesign
please
in
Austin
offline,
as
I
mentioned
in
the
agenda,
I
did
get
a
coupon
code
for
one
hundred
free
stickers,
so
obviously
I'm
not
gonna
do
anything
with
that
until
we
resolve
it
next
week,
but
I
guess
that's
not
it
then
any
other
any
comments.
Questions
concerns
about
that
plan
and.
A
We
have
a
conference
coming
up
in
the
near
future.
That
way,
you
know
that
we
may
want
those
100
stickers
out
so
I
think
we
do
that
some
time,
but
I
do
want
to
get
the
resolved
sooner
rather
than
later,
especially
since,
what's
the
new
design
cos
forward,
we
will
take
a
vote
and
that
will
take
some
time
too.
A
E
Absolutely
on
Monday
this
week
we
had
the
initial
call
around
designing
the
cloud
event
SDK.
It
seemed
like
a
bunch
of
people
already
working
on
this
independently
and
a
bunch
of
different
companies.
So
we
said:
hey,
maybe
there's
a
maybe
we
should
do
this
together
and
then
that
kind
of
inspired
this
call.
So
a
handful
of
people
jumped
on
the
call
VMware
s,
ap,
Red,
Hat
Google,
and
we
chatted
loosely
about
this.
We
were
able
to
draft
out
use
cases,
features
goals
for
the
SDK.
We
were
able
to
rank
them
by
priority.
E
We
were
also
able
to
organize
them
into
potential
versions
of
the
SDK.
And
lastly,
we
found
volunteers
for
implementations
across
various
languages,
those
languages
being
Java,
Go,
JavaScript
and
Python
right
now,
so
a
pretty
good
progress.
We've
tracked
everything
in
the
cloud
event:
SDK
design
proposal,
Google
document,
which
you
can
see
I-
think
that's
in
this
working
group,
Google
Doc,
right
Doug,
maybe.
E
E
E
Thing
and
again
this
isn't
a
Google
Doc
o'clock
already
commenting
on,
so
you
don't
have
to
speak
up
within
this
small
time
box.
You
could
always
speak
speak
up
later
by
adding
a
comment
on
the
Google
Doc
number
one.
The
first
initiative
that
we
felt
was
the
most
important
was
to
simply
be
able
to
instantiate
cloud
events
easily
in
code
per
the
current
cloud
about
specification
and
have
some
simple
API
is
around
those
businesses
that
you
creates.
You
get
and
set
data
on
the
cloud
of
an
instance
and
work
with
the
cloud
event
more
easily.
E
You
should
be
able
to
you
know,
also
kind
of
mock
these
things
out
for
testing.
In
addition
to
that,
we
we
like
to
figure
out
how
to
design
this
SDK
to
support
different
versions
of
the
cloud
event
specification.
You
know
we
think
we're
still
going
to
be
iterating
on
the
on
the
core
spec
for
a
while,
and
the
SDK
needs
to
think
about
that
from
the
beginning.
E
So
that
was
the
first
priority
and
then
we
felt
was
kind
of
the
simplest
thing
we
could
do
today
to
get
to
enable
users
to
start
using
cloud
offense
as
fast
as
possible.
The
second
big
priority
was
to
assemble
cloud
events
from
various
transports
and
encodings
and
have
the
SDK
helped
with
some
of
that
work,
and
to
do
this
adhering
to
the
various
kind
of
transport
specifications
that
we're
working
on
right
now,
like
HTTP,
AMQP,
Nats
web
hooks
and
qtt.
E
That
was
the
second
priority
we
felt
was
was
important
third
instantiating
cloud
of
its
easily
via
event
schemas,
and
this
specifically
means
the
schema
of
the
data
within
the
cloud
events,
data
attribute
and
not
the
entire
cloud
event
itself,
so
being
able
to
pass
in
an
event
schema
and
and
using
that
to
create.
You
know
II,
easier
defaults
of
cloud
events
to
do
some
validations
to
be
able
to
validate
the
cloud
event
by
that
schema
and
even
more
easily
generate
mock
events
from
that
schema
as
well
number.
Four.
E
E
You
know
enable
end-users
to
kind
of
build
their
own
to
use
their
own
extensions
with
on
the
specification
and
kind
of
integrate
that
into
the
cloud
events
SDK,
as
well
as
a
vendors,
your
vendors,
who
might
have
some
some
kind
of
proprietary
things
that
they
want
to
put
on
the
cloud
events
envelope
and
also
have
a
nice
story
with
with
inside
the
SDK.
So
that
was
the
fifth
priority
we
felt
was
important.
That's
everything!
E
A
E
Good
question:
Kathy:
a
lot
of
people
have
already
started
these,
so,
for
example,
Matt's,
yes,
Matt
see
us
over
at
Red,
Hat
and
his
crew
are
cruising
along
on
the
Java
implementation.
I
know,
mark
peek
and
his
crew
over
at
VMware
and
dispatch
have
a
go
version
in
the
works.
There's
a
Python
version
that
has
already
been
started
and
I
think
that
it's
yeah.
This
is
one
question
that
I
wanted
to
raise
to
this
group.
E
You
know:
we've
laid
out
the
milestones
and
scope
for
the
cloud
events,
SDK
version
and
I
think
that's
an
important
exercise
to
kind
of
stack
rank
where
we
think
the
priorities
are
and
get
aligned
on
what
the
on
what
the
SDK
design
should
look
like
across
languages.
However
I'm
not
personally
feeling
like
this
should
be
used
to
block
anyone.
E
C
E
Yeah,
that
was
gonna,
be
the
last
item.
I
was
gonna,
bring
up
here
after
just
getting
some
feedback
on
those
priorities.
You
know
I.
Think
I
I
think
that
we
should
do
an
additional
meeting
just
to
clarify
some
of
this,
the
scope
of
the
initiatives
that
we've
prioritized,
because
some
of
them
can
be
quite
broad
and
hopefully
aligned
on
design
patterns
so
that
these
these
implementations
can
look
more
consistent
across
runtimes.
So
I
think
that
would
be.
E
That
would
be
a
good
good
subject
matter
to
discuss
in
an
upcoming
call,
but
perhaps
after
that,
I'm
not
sure
if
we
need
to
do
a
recurring
call,
I
think
we
should
let
people
implement
for
a
little
while
and
then
do
kind
of
a
check-in.
You
know
once
we
think
we
have
a
few
implementations
on
the
table
so.
E
F
D
A
E
Everyone's
already
kind
of
jumping
into
implementation,
people
are
moving
really
fast.
You
know
I
I'm
personally,
really
excited
about
this
I
think
we've
we're
doing
some
important
work
here.
We
have
a
great
spec
on
the
table.
These
SDKs
are
gonna,
make
it
more
accessible
and
make
it
real
and
allow
people
to
put
this
into
their.
You
know
start
actually
using
this
stuff
or
easily
than
ever
so
excited
to
see
the
enthusiasm
around
this
and
I
think
we're
gonna
make
a
lot
of
progress
quickly.
A
F
J
Ok,
good
thing:
Kathy,
like
I
I
kind
of
struggle,
a
couple
of
times
to
figure
out
what's
happening,
I
didn't
know
how
to
get
in
touch
with
you.
I
was
trying
to
reach
in
slack
reply,
wrote
on
the
doodle
I,
don't
know.
What's
the
best
way
for
us
to
kind
of
communicate
to
kind
of
make
sure
people
know
this
is
happening.
Obviously
this
meeting
is
one
way
to
do
it,
but
I
don't
know
like
well
is
taking
meetings.
I
know
when
they
were
happening
because
they
all
questions
like.
A
F
F
A
F
You
know
for
people
who
are
interested
in
this
topic:
I
have
a
Google
Doc
and
that
drafting
the
that
drafts
the
kind
of
overview
of
the
workflow.
So
if
you
can
take
a
look
at,
that
would
be
good.
Can.
A
F
E
Post
potential
suggestions
I'm
going
to
make
a
issue
within
the
cloud
events
spec
repo
right
now,
it's
just
going
to
be
called
logo
improvements.
If
you
have
suggestions
for
logos,
I
recommend
just
putting
them
just
pasted
in
the
artwork
right
in
that
issue
thread
and
hopefully
doing
this
all
before
next
Thursday
in
the
next
Thursday.
We
could
kind
of
look
at
these
and
and
vote
on
them
together.
It.
A
All
right
moving
forward,
then,
so
we
have
two
issues
which
we
said
we're
going
to
close.
Unless
someone
spoke
up
to
my
husband
there
we
go
unless
someone
speaks
up
to
claim
a
champion
of
these
two
issues.
So
the
first
one
was,
as
conformance
with
Jason
API
spec
I
haven't
seen
anything
claiming
to
be
an
owner.
A
Is
there
a
final
objection
to
closing
this
one,
and
just
remember
this
doesn't
mean
we
can't
reopen
it,
but
at
this
point
in
time,
without
someone
willing
to
champion,
let's
move
forward
on
this,
it
doesn't
seem
like
there's
much
interest
in
it,
but
we
can't
reopen
it
if
that
changes
in
the
future.
So
any
objection
to
closing
this
one
with
no
action
all
right
and
what
about
the
other
one
alignment
with
IETF
security
event.
Token
again,
I,
don't
believe,
there's
been
any
interest
of
anybody
in
this
one.
A
A
K
A
Like
all
the
other
specs
and
our
repo,
this
is
just
sort
of
the
first
draft
for
the
most
part,
I
just
rearranged
things,
I
tried
to
move
things
like
use
cases,
references
to
existing
event,
format,
stuff
out
of
the
main
spec
itself
into
the
primer
and
add
a
little
bit
of
text.
Try
to
explain
some
of
the
history
of
the
group
itself,
where
we're
going
design
goals.
It's
like
stuff
like
that,
and
this
way
it
will
keep
this
itself
focused
on
sort
of
the
normative
text
itself
and
any
sort
of
ramblings
or
background
history.
A
That
kind
of
stuff.
We
can
move
into
this
primer
dock
and
have
it
all
in
one
spot,
for
people
to
read
as
background
material
I.
Don't
want
us
to
go
through
it
all
right
here,
but,
as
you
can
see,
most
of
it
is
just
moving
stuff
around
for
the
most
part.
That's
why
you
see
a
lot
of
deletes
and
then
copied
into
the
new
dock
itself.
Are
there
any
questions
on
this
any
concerns
or
any
reason
you
want
to
wait
a
little
bit
longer
before
we
accept
this
or
discuss
the.
A
F
A
F
A
A
camera
which
one
went
to,
which
section
to
be
honest,
I,
think
part
of
the
use
can
stick
a
little
roles
and
then,
and
then
some
of
it
I
think
pop
showed
up
under
value
proposition,
because
that
seemed
to
be
more
appropriate
title
than
use
cases.
But
obviously
you
can
change
the
titles
if
you
guys
want
them.
I,
don't
really
care
that
much
about
the
titles,
but
the
text
itself
should
still
be
there.
F
C
Hey
guys,
I
think,
given
that
the
questions
are
being
asked.
Perhaps
this
is
called
action
for
people
to
review
it,
and
then
we
can
approve
this
next
week.
That's
as
far
as
well
I've,
no
objection
to
waiting
it's
just
so
people
have
a
week
to
view
and
make
sure
that
those
sections
got
trim
transposed
forever.
Okay,.
F
B
A
K
A
You
know
how
the
normative
I'm,
sorry,
the
the
RFC
keywords,
apply
only
within
the
context
of
the
extension
itself,
meaning
for
example,
believe
down
here
kiss
keep
a
concrete
thing
down
here
when
he
says
this
is
required.
That
means
it's
only
required
if
you're
choosing
to
use
the
extension,
it
doesn't
mean
it's
required.
You
know
for
all
for
all
uses
of
the
cloud
venting
spec
itself,
but
for
the
most
part
I,
don't
think
he
actually
made
any
real
changes.
A
G
A
A
Yes,
fairly
straightforward,
he
just
added
some
items
to
our
roadmap,
just
basically
I
believe
here.
The
point
is
he
wanted
to
add
the
idea
of
making
sure
we
actually
looked
at
the
specification
from
a
constraint
perspective.
You
know
our
our
we.
We
need
to
add
limitations
on
sizes
to
to
values
and
stuff,
like
that.
Just
want
to
make
sure
that
you
know
that
the
real
world
constraints
actually
were
reflective
are
cleaner
analysis
here.
So
we
just
wanted
to
add
these
to
our
milestones
or
to
our
roadmap
and
it's
fairly
straightforward
in
short
list.
It.
C
A
A
This
PR
is
related
to
something
we
talked
about,
I,
believe
it's
a
face
to
face
and
actually
probably
before
that,
if
the
idea
of
removing
the
the
bag
that
we
had
for
extensions
or
the
map
that
we
have
for
extensions
and
treating
extensions
as
top
local
entities,
so
the
bulk
of
the
PR
is
actually
right
here
and
here's
the
only
real
nerve
normative
text.
Basically
that
producers
may
include
additional
extension
attributes
and
then,
if
you're
typing
he's
going,
you
sew.
Em
producers
can
include
additional
extensions.
A
They
appears
top
level
attributes,
but
the
definitions
for
the
serialization
and
the
transport
bindings
will
actually
specify
how
extensions
will
appear
in
that
particular
context.
So
the
main
spec
itself
basically
avoids
that
issue
or
punts
on
it
and
then
they've,
the
like
the
HTTP
spec
itself
will
define
how
extension
tool
appear.
A
A
C
A
Basically,
because
there
were
multiple
I'm
sorry
if
we
have
a
a
bag
for
extensions,
you're
then
left
with
the
situation
where
you
have
multiple
places
for
extensions,
so,
for
example,
in
the
Chasen
serialization
you
could
have
the
bag
for
extension
at
one
spot,
but
then
jason,
the
top
level,
would
allow
you
to
add
additional
properties
in
there.
So
then
the
question
comes:
while
do
you
put
extensions
at
the
top
level,
jason
or
inside
the
bag?
I
A
good
point
that
the
pr
raises
is
the
path
to
stabilizing
a
experimental
extension.
Basically
promoting
it
to
your
first
class
is
essentially
a
epi
breaking
change.
If
we
use
this
bag
of
extensions-
and
I
think
this
is
kind
of
a
more
general
problem,
it
would
also
affect
things
like
the
Java
SDK,
because
the
way
you
access
extensions,
I
imagine
would
be
different
from
you
know,
actual
getters
and
setters.
So
I
just
want
to
raise
a
point.
I,
don't
really
have
a
good
solution
for
it.
Yet
right.
A
So
it
sounds
like
some
people
may
not
have
had
a
chance
to
think
about
this
one
so
which
is
fine
since,
as
I
said,
we're
not
gonna
miss
a
vote
on
this
today.
So
please
take
some
time
to
review
this
comment
in
the
PR
itself.
We
don't
want
to
wait
for
this
phone
call
to
go
through
larger
issues
around
this
I'd.
Rather
do
it
offline
and
PR
itself.
So
please
think
up
in
there,
if
you
guys
have
any
concerns
or
questions
I.
B
A
N
A
Very
fair!
Yes,
yes,
so
anyway!
Obviously
this
is.
This
is
kind
of
a
big
one
in
the
sense
that
it's
it's
a
it's
a
it's
a
key
design
point
right.
So
please
take
the
time
to
review
it.
Look
at
the
discussions
that's
going
on
in
there
and
and
comment
on
the
PR,
so
we
can
get
some
feedback
on
either
way.
One.
B
Of
the
one
of
the
objections
from
the
notes
from
the
face
to
face
was
that
it
would
be
difficult
to
do
in
proto
and
I.
Imagine
the
Google
cares
about
that
more
than
other
places,
so
I
will
take
it
on
as
a
AI
to
figure
out
what
are
like
what
Google's
stance
is
going
to
be
on
like
how
we
can
do
this.
Okay,.
A
A
F
I
think
this
one
has
been
iterated
as
multiple
times
and
so
I
wanted
to
have
IRA
modified
it
based
on
now
our
consensus
in
the
face-to-face
meeting.
So
people
can
take
a
look
to
see
whether
this
is
okay.
A
Well,
I
think
that's
a
general
certain
things.
I,
don't
think
Cathy
changed
the
pattern.
That
may
be
something
we
want
to
address
a
broader
scale
than
Scott,
but
so
Cathy
a
couple
things
first,
I'm
not
sure
we
want
to
allow
spaces
and
names.
Oh.
F
A
string
right
so
what.
A
A
No
I
want
the
names
to
be
non
spaces,
but
in
some
cases
these
gonna
get
mapped,
HTTP,
headers
and
I.
Think
spaces
might
have
a
cost
problems
there.
So
that's
what
you
say.
You
probably
say
something:
that's
suitable
for
use
as
an
HTTP
header,
yeah.
That's
why
I
have
my
assistants
to
say
how
they
often
American.
A
A
F
Different,
so
flat
structure
means
you
know
we
do
not
have
hierarchy.
Remember
in
the
previous
there's
a
proposal
which
has
hierarchical
this
I
tree
is
properties
right.
A
F
L
A
A
E
P
P
P
I
but
the
request
I
think
if
this
is
I'm
hearing
from
the
group
I'm
not
participating
discussions.
If
you
wanna,
if
there's
text
there
are
way
that
can
be
preserved,
please
do
you
so
I
mean
if
something
else
is
hands,
gonna
be
in
this
section.
It's
just
a
sentence:
I
really
don't
want
to
become
involved,
Emma
Terry,
so.
A
Kathy
I
think
what
matters
is
just
thing
is
that
you
could
say
the
value
must
be
a
string
and
then
maybe
add
in
parenthesis
or
something
here
that
says,
because
we
want
to
keep
it
as
a
flat
structure
or
something
like
that.
Just
to
give
it
a
little
bit
of
rationale
to
explain
why
we
chose
to
keep
it
a
string.
F
P
A
P
A
F
A
Right
so
this
actually
goes
a
little
bit
to
my
comment
that
I
didn't
make
on
the
pier
itself
in
the
body
which
is
here,
I
I,
given
the
text
that
we
have
in
this
PR.
As
somebody
coming
new
to
the
spec
and
I
would
read,
this
I
would
still
be
very
confused
as
to
when
I
would
use
this
versus
extensions.
K
A
O
A
O
F
Just
feel
we
are
like,
don't
know,
run
the
loop
again
I
think
you
know
in
the
face-to-face
discussion
already
discussed
this
right
of
how
we
should
restrict
the
scope,
and
then
we
come
to
consensus
say
you
know
this
is
for
originally
I
was
thinking
visit
just
for
correlation
purpose,
but
then
you
know
we
think
we
understand
I
mean
this
fine
late.
He
said
it's
used
to
buy
application,
Nikki
border
right.
A
But
Cathy,
one
of
the
things
that
we
also
agreed
to
at
the
face-to-face
was
to
make
sure
that
there
is
sufficient
text
in
here
to
explain
why
we
have
these
two
different
extensibility
points
and
when
one
should
be
used
instead
of
the
other
and
I.
Don't
think
the
text
in
here
does
that
yet
and
so
I
think
we
need.
We
need
additional
explanation.
Text
in
here
is
the
point
I'm
trying
to
get
to.
H
O
F
I
think
we
clarify
some
of
those
are
not
really
a
correlation.
It's
maybe
different.
You
know
use
the
same
same.
You
know
same
syntax
same
word,
but
this
Mattox
is
different.
I'm
actually
I
personally
would
like
to
just
this
is
for
Carnegie.
You
know
multiple
events
from
different
event.
Sources
for
that
purpose.
I
can't
restrict
that,
because
I
think
you
know.
F
Well,
so
what
what
people
would
have
to
pay?
What
how
your
suggests,
you
think
you
know,
should
be
put
here,
because
there
are
so
many
examples,
yeah
car
taking
multiple
events.
They
are,
you
know
different
use
cases.
You
can
put
different
things
there,
I,
don't
know,
you
know
how
we
should.
You
know,
restrict
this
I.
K
F
F
Think
of
it.
You
know
we
cannot
restrict
it
anymore
or
because
the
different
use
there
are
many
such
use,
cases
which
were
going
to
there
many
different
types
of
events,
different
types
of
event,
sources.
We
cannot
predefined,
like
you
know
what
what
properties
will
be
used
for
correlating
those
events,
so
it's
open
to
whatever
part
whatever
that
I
mean
the
the
developer,
are
they
can
put
in
I
mean
all
the
event
even
hangar.
They
can
put
any
parties
there,
which
they
think
could
be
used
to
correlate
multiple
events,
but.
A
A
F
So,
that's
that's
why
you
know
if
we
just
put
correlation
it's
already
big
enough
right.
People
are
already
thinking
some
people,
I
guess
some
people
were
thinking.
Okay,
it's
still
not
clear
what
should
be
put
there
at
least
extended
expanded
to
include
you
know
more
use
cases
or
be
even
harder
for
people
to
understand
what
should
be
put
there
to.
B
O
F
F
F
O
O
F
You
know
I,
think
you
know
we
we
can
just
put
it
right
here,
I
already
put
say
one.
Your
system
usage
example
is
application.
Workflow
can
use,
is
key
value
pair
to
carry
multiple
events
or
social
service
application
right
from
different
event.
Sources.
I
think
this
itself
by
itself,
the
nature
is,
is
quite
open.
I,
don't
think
you
know,
we
really
need
to
restrict
it,
because
if
we
restrict
it
will
be
wrong.
You
know
it.
That's
not
its
nature
for
this.
F
P
F
So
if
it's
okay,
I
think
this
is
a
little
bit
complicated,
let
me
try
to
clarify
even
it's
a
single
event
right
so
that
event,
if
that
event,
from
application
perspective
from
my
events,
shows
perspective,
every
event
is
a
single
event
right
from
an
application
perspective,
that
application
could
use
multiple
events,
which
includes
that
so-called
single
event.
You
know
you
know
I'm,
not
sure
that
I
can
get
this
across.
You
know
this
is
not
from
an
event
perspective.
You
know
every
event
is
a
single
event.
B
F
If
the
application
is
trying
to
okay
yeah,
so
so
the
application
of
what
it
works
is
this
event
source.
Even
when
they're
put
this
information
there
right
like
this
public
address
or
the
floor
apartment
ID,
and
then
the
application
workflow
will
say:
okay
I'm
going
to
choose.
You
know
this
like,
for
example,
these
are
sensor,
location
and
plus
apartment
ID
and
process
address
all
these
as
my
correlation
ID
and
then
for
another
event,
he's
going
to
use
the
same
information
but.
B
If
so,
that's
in
one
application
and
if
I
have
another
application,
that
is
not
correlating
events
at
all
like
the
application
it
gets.
It
gets
an
event
and
it
performs
some
action,
but
it
doesn't
need
to
classify
the
events
in
any
way.
What
would
they,
since
this
is
required?
What
would
they
put
in
there?
Okay.
F
So
that
application
does
need
to
put
any
to
select
any
attribute
any
any
field,
any
keys
from
this
practice,
but
that's
the
application
level
is
optional,
but
from
the
event
source
level
is
required,
because
if
there
is
a
application
that
need
to
do
correlate,
if
this
information
is
not
in
that
event,
then
that's
a
problem.
So
it's
that's
a
very
good
question.
Rachel,
you
asked
so
from
the
event
shows
perspective
it's
required
because
if
the
event
does
not
have
it,
if
a
medication
needed
it
cannot
do
it
so.
A
I
have
to
call
time
here
just
because
at
a
time
basically,
but
these
people
please
add
comments
to
the
pier
itself,
asking
all
those
questions,
because
these
are
all
really
really
good
questions
that
we
need
clarity
on,
but
please
put
them
into
the
PR
it's
else
we
can
get
some
conversations
going.
Oh,
we
shouldn't
be
doing
this
much
deep
dive
on
the
calls.
So
we
should
be
doing
this
on
the
pier
itself.
So
please
take
time
to
review
this
and
we'll
revisit
this
one
again
next
week.
I
think.
F
You
know
doc:
yeah
I
said
we're
running
out
of
time,
so
I
I
think
this.
This
thing
itself
by
Nature
is
really
open,
so
I
think
when
people
post
questions
yeah
I'm
going
to
try
to
answer,
but
if
also
I
would
like
people
to
post
suggestions
on
because
I
think
it's
open,
I,
don't
know
how
I
should
put
any
any
restriction
or
anything
there.
Yes,
please.