►
From YouTube: CNCF Serverless WG 2020-05-21
Description
CNCF Serverless WG 2020-05-21
A
C
A
D
A
G
H
A
C
A
I
A
A
F
K
F
A
A
Is
an
option
is
we
are
lucky
that
in
our
in
our
line
of
work,
we
can
work
from
home
if
our
company
lets
us.
So
that's
good.
Alright,
it's
it's
it's
for
after
we're
way
behind
sorry
for
that
diversion,
alright,
alright,
nothing
for
a
eyes,
okay,
community
time,
anything
from
the
community.
If
you
want
to
bring
up.
K
A
If
you're
interested
seeing
the
rest
mo
join
that
first
five
minutes,
but
it
should
be
interesting,
so,
if
you're
interested,
please
join
all
right,
so
the
cig
update.
This
is
interesting,
so
I
think
last
week
I
mentioned
that
the
TOC
seemed
like
they
were
more
in
favor
of
us,
creating
a
sig
as
opposed
to
just
being
a
work
group
under
sig
app
delivery.
A
Unfortunately
I'm
starting
to
get
the
sense
now
that,
maybe
that's
not
true,
or
at
least
one
of
the
people
on
the
TOC,
definitely
does
not
think
we
should
go
that
path.
They
want
us
to
remain
a
working
group.
So
I
basically
said
we
don't
care.
What,
if
you
guys
want
to
just
let
us
know,
because
I
don't
want
to
get
into
an
endless
wordsmith
thing
to
try
to
define
serve
lists
so
that
it
differentiates
us
enough
from
sick
after
the
veriest.
A
In
my
opinion,
that's
all
the
same
thing,
so
we're
gonna,
let
them
decide
and
I,
don't
know
what
their
decision
is
yet
I'm
gonna
lean
on
the
COC
to
make
that
decision.
For
us
we
just
don't
give
a
crap
to
be
blunt
about
it.
So
it's
still
up
in
the
air.
Just
let
you
guys
know
all
right
moving
forward,
though
there
isn't
a
CK
call
after
this
one.
If
we
end
early,
we
will
start
that
early
so
be
prepared
for
that.
Let's
see,
I
don't
see
team
we're
on
the
call.
A
So
I
don't
think
things
update
there
other
than
keep
in
mind.
They
do
have
any
of
their
own
repo.
Now
I
did
manage
to
convince
the
powers-that-be
to
give
the
workflow
group
their
own
repo,
so
they
can
move
their
stuff
out
of
the
service
github
repo
because
they
felt
a
little
bit
like
they
were
being
shortchanged
by
being
just
a
folder
under
that
repo
and
they
wanted
to
be.
A
They
want
to
be
able
to
advertise
themselves
a
little
bit
more
and
point
to
a
folder,
wasn't
quite
as
nice
as
a
full-blown
repo,
so
I
didn't
manage
to
get
them
a
repo
and
they
are
still
trying
to
figure
out
the
process
for
becoming
a
sandbox
project
and
we'll
see
how
that
plays
out
and
I.
Think
that's
the
only
thing
worth
mentioning
going
on
there.
A
Now
it
was
notice,
that's
the
master
or
head
versions
of
our
documentation.
I'll
say
v1
point
though,
and
well
a
lot
of
them
haven't
changed
for
some
things.
They
actually
have
and
that's
a
little
misleading,
because
technically
they're
in
the
process
of
being
coming,
maybe
a
version
1.01
at
some
point.
Well,
whatever
the
whatever
their
thing.
Is
it's
not
technically
one
point,
though,
so
we
should
probably
name
them
something
different
at
the
head
level.
A
In
the
past,
we've
named
it
V,
whatever
the
next
version
is
going
to
be
RC
one
just
to
make
it
clear
that
it's
nuts,
it's
a
candidate,
it's
not
official,
it's
just
a
work
in
progress,
so
I
was
thinking
of
doing
the
same
thing
here
and
for
now
calling
it
V
0.1
RC
one.
We
could
also
use
WIP
any
work
in
progress.
I,
don't
have
a
strong
preference,
but
I
figured
I
need
to
get
input
from
you
guys
to
see
whether
you
care
one
way
or
the
other.
A
D
A
A
Okay,
just
let
me
strike
a
run
a
time
all
right,
so,
as
promised
Clemens
sent
in
his
proposal
for
the
schema
registry
and
I
see
okay,
there
are
some
comments
in
there.
I
had
a
chance
to
look
at
myself,
but
he
did
he's
Duty
promised
now,
because
he
just
sent
this
in
yesterday,
it's
too
soon
for
us
to
officially
vote
on
whether
we
merge
it
or
not,
and
unfortunately,
with
him
not
being
on
the
call
he's
not
here
to
take
any
questions,
but
for
posterity
and
the
recording.
A
It
do
there
you
go
okay,
as
I
said.
Obviously
we
don't
need
to
anything
with
it
right
now.
This
is
I'm
just
bringing
this
up
more
for
you,
guys,
FYI,
so
that
everybody
can
take
a
look
at
it.
Then.
Hopefully,
the
next
week's
call
will
either
discuss
it
or
vote
to
approve
it
as
a
working
draft
that
should
be
merged.
Some
people
can
then
do
PRS
and
issues
against.
A
Comments
commentary
all
right
moving
forward.
Then,
okay,
tell
you
what
let
me
do
this
gemst
I
just
noticed.
You
join
the
call
since
we
can't
vote
on
this,
and
you
just
said
it
yesterday.
Let
me
give
you
a
chance
just
to
introduce
this
issue
or
a
PR
I
should
say
just
so.
People
are
aware
of.
It
then
can
review
it
for
next
week.
M
You
know
this
is
when
the
dangers-
I
guess
I'm
sitting
at
home,
putting
my
thumbs
and
wondering
what
to
do
so.
I.
You
know
we
had
the
protobuf
or
a
protobuf
suggestion
and
we
yanked
it
and
just
before
v1
icon
member,
exactly
why
we
did
that,
but
it
got
yanked
and,
as
I
hadn't
seen
anything
coming
back,
I
thought
I
would
take
a
cracker
creating
you
know
a
version
of
that
I've
basically
taken
an
approach.
I
know.
M
If
you
want
to
go
to
the
the
schema
file,
it
sort
of
fully
encapsulate
a
protobuf
representation
of
a
cloud
event,
so
it
allows
for
yo
a
set
of
attributes
and
then
a
distinct.
You
know
payload
and
one
of
those
payloads
could
be
a
protobuf
object
itself.
You
know
so
much
like
in
Jason.
You
allowed
the
body
to
be
a
JSON
document.
This
allows
it
to
transport
a
prose
of
our
objects
as
if
they
wanted
I
took
the
approach
of.
M
Defining
the
attributes,
in
terms
of
you
know
the
cloudy
then
attribute
types
or
our
type
system,
so
using
this
model,
I
believe
we
can
carry
or
represent
any
yo
type
that
we
want
within
our
type
system.
The
only
thing
I
haven't
done,
and
this
was
I-
think
where
I'm
looking
for
guidance
is
I,
took
the
stance
of
just
defining
all
the
attributes
as
a
map,
rather
than
calling
our
individual
property
fields
for,
like
the
spec
version
and
the
type
those
sort
of
required
fields
I'm
still
mentally
on
the
fence.
K
So
I'll
tell
to
you
that
I
ever
really
really
little
knowledge
on
protocol,
but
what
I
see
here
that
I
don't
understand
honestly
and
again,
that
could
be
because
my
little
knowledge
about
protein
off
is
why
you
did
one
off
on
the
data
I
mean
this
was
I,
think
in
even
format
in
the
JSON,
even
format.
This
was
originally
down
to
make
easier
to
read
the
cold
event
when
when
it
says
instructor
mode,
but
in
that
case
you
already
sent
the
protobuf
as
a
binary.
So
what
is
the
reason
behind
doing
data
one
off
so.
K
M
I
mean
much
like
I
guess.
My
argument
would
be
in
Jason.
We
allow
a
JSON
object
to
be
natively
inside
the
data
payload
yeah,
so
certainly
from
a
protobuf
perspective.
I
can
just
natively
put
a
proto
object
in
the
payload
as
well.
Yeah
I,
don't
need
to.
You
know,
trying
to
hide
it
inside
a
byte
string.
I
can
just
natively
represent
it.
A
part
of
this
has
actually
come.
K
M
Had
a
lot
of
people
coming
to
me
saying
well,
why
is
that?
You
know
that
the
content
type
tells
you
what's
in
the
string,
so
why?
Why
do
we
need
to
treat
them
differently?
I,
also
think
if
you,
if
we
represent
by
its
explicitly,
then
you
know
it's
a
protobuf
marshalling
as
to
how
those
get
put
on
the
wire
it's
I,
don't
have
to
do
any
application
encoding.
You
know
it's
just
a
buffer
I!
Just
stick
it
on
there.
M
We
don't
really
care
yeah
I,
don't
have
to
encode
that
byte
string,
those
bytes
into
a
string
to
be
able
to
carry
them
and
comment
about
how
that
Avro
addressed.
This
I
must
admit:
I
haven't
looked
at
the
Avro
spec
I
I,
don't
know
it's
that
if
ever
I
allow
you
to
carry
roared
rawrr
bytes,
but
that
was
my
thinking
yeah.
If
it's
a
binary,
payload
I
can
just
pass
it
as
a
binary
payload.
A
D
A
Well,
everything
I
said,
though,
that
I
know
we
have
some
Google
folks
on
the
call,
and
so,
if
you
guys
can
maybe
poke
some
protobuf
experts
within
the
company
to
take
a
look
at
this
I'd
love
to
get
their
opinions
on
it.
I
I
already
picked
Evan
Anderson's
I
know
he
was
one
of
the
first
folks
I
said
no,
he
didn't
create.
There
isn't
one
we
had,
but
he
was
definitely
looking
at
the
one
we
had
a
long
time
ago
and
I
think
he
may
have
been
the
one
that
suggested.
A
M
M
A
I
Your
hands
up
so
I
had
a
question
around
the
context
in
the
consumption
right.
What
I
mean
by
that
is
obviously,
when
you're
using
protobufs
to
serialize,
you
need
study,
serialization
capabilities.
How
does
that
handshake
happen?
How
is
that
expected?
Is
there
a
type
of
encoding
or
something
like
that?
Is
that
and
that's
not
clear
to
me
from
this
pull
request,
maybe
just
adding
a
little
bit
more
context
around.
It
will
also
be
really
helpful,
as
we
think
about
this,
so.
M
I
Not
the
question
I
think
the
question
is
as
a
sender,
let's
say:
I
choose
to
use,
photobooth
and
I,
see,
realize
it
and
I
send
it
out
and
as
a
consumer.
How
do
I
know
that
it
is
I
need
the
it's
a
Prada,
buff
serialization
and
use
the
consequent
deserialization
capabilities
as
opposed
to
a
draw
or
JSON.
M
M
So
let
the
transport
layer
so
much
like
in
the
JSON
format.
You
say:
if
it's
a
structured
payload,
then
we
say
cloud
events
plus
Jason,
so
here
you
know
if
you're,
using
HTTP,
for
instance
and
content
height
would
be,
would
be
what's
shown
on
the
screen
there.
So
that's
how
your
my
understanding
from
a
cloud
event
perspective.
Is
that
that's
how
we
differentiate
and
it's
a
structured
event,
because
it's
applications
last
cloud
events
plus
yeah
and
then
the
actual
encoding
or
content
type.
Is
what
follows
after
that?
M
A
M
A
I
One
more
question:
Doug,
as
I've
been
a
part
of
this
team
for
like
two
months,
I'm,
just
wondering
as
we
start
supporting
newer
encoding
schemes,
a
touch
of
what
kind
of
out-of-the-box
testing
capabilities
do
we
have
that
we
can
do
you
know
quickly
test
these
kinds
of
things
run
these
quick
tests
and
so
on.
This
is
something
that's
readily
available,
or
should
we
start
thinking
about
having
that
kind
of
capability,
so.
A
I'm
not
sure
we
have
a
whole
line
now
beyond
what
the
SDKs
offer,
but
I'm
gonna
poke
on
Scott
here
for
a
sec,
because
I
know,
Scott
has
done
a
lot
of
thinking
around
performance
test
Suites
and
it's
something
not
necessarily
a
hundred
percent
relate
to
what
you're
asking
but
I
think
it
kind
of
touches
on
it
a
little
but
I
think
that's,
probably
the
closest
thing
we
have
sort
of
in
the
works
Scott.
You
want
to
comment
a
little
on
that.
I
G
A
A
So
since
last
time
we
talked
oh,
thank
you
Vinay,
there's
a
link
in
the
chat
from
Scott.
If
you
want
to
go
through
performance
stuff,
since
the
last
time
we
talked
I,
think
the
only
real
change
I
may
have
made
is
oh
fudge.
I
think
I
forgot
to
push
I
thought.
I'd
changed
this
from
service
to
something
different
I
forgot
to
push
it
darn.
It
I
turned
what
I
made
it.
D
A
A
Okay,
yeah
so,
and
the
previous
version
of
this
I
think
I
had
a
source
class
or
something
like
that
and
then
I
changed
it
to
service,
because
I
thought
that
might
be
a
better
representation
of
the
abstract
concept
of
this
thing,
that's
gonna
be
generating
potentially
lots
of
different
events
for
lots
of
different
sources.
I,
don't
know
whether
service
is
good
enough
or
whether
it's
overloaded,
because
everything
out
there's
a
service
these
days.
But
that's
that's
my
initial.
A
A
L
A
Okay,
so
the
name
so
there's
to
me,
there's
two
different
parts
of
this
PR
there's
one
which
is
you
know,
sort
of
adding
the
the
text
up
here.
This
pseudo
yeah,
mul
type
stuff,
there's
a
little
bit
of
word.
Smithing,
that's
one
piece
and
obviously
a
big
part
of
that
is
the
word
service
and
services
as
opposed
to
what
was
it
called
before
start
with
a
P
producer
provider,
one
of
those
right
then.
A
The
second
part
is
the
examples
that
talk
about
how
to
do
queries-
and
that's
this
thing
down
here
and
what
I'd
like
to
do
is
I
guess:
split
the
discussion
in
the
two
first.
Is
there
any
concern
about
the
the
first
part,
the
word
some
of
thing,
the
use
of
service
and
nothing
set
in
stone.
So
we
can
change
it
later,
but
like
the
first
focus
on
the
the
word
smithing
part
more
than
anything
else,
so
then
we'll
talk
about
the
query
part.
Second,
so
Scott
your
hands
up,
yeah.
A
A
A
And
I
bet
I'd
at
least
to
me
anyway.
I
think
the
entity
that
goes
here
is
bigger
than
just
a
single,
a
single
thing
right,
it's
it's!
It's
almost
like
the
global
Apple,
it's
like
if
it's
an
object,
store
right.
It's
like
or
get
up.
Let's
pick
on
get
up.
If
github
is
a
service,
it's
that
I,
don't
think
I'm
gonna
say
as
an
origin
per
se,
Cydia
producer
well
I'll
see.
Then
we
get
back
to
that
problem.
We
had
before
where
producer
and
provider
are
too
close
together.
People
are
gonna
mix.
I
Take
the
service
michig
sample
rank,
you
have
like
a
container
in
a
pod,
and
then
you
also
have
a
proxy,
for
example,
and
then,
if
the
proxy
is
sending
stuff
on
behalf,
so
maybe
in
my
suggestion
was
to
try
to
distinguish
from
given
our
discussion
from
last
time,
how
about
originator
to
actually
distinguish
and
identify
the
the
entity
that
was
sending
originate,
literally
originated
the
event
and
then
the
to
identify
the
proxy,
which
is
that
bigger
system.
If
you
will
that
you
describe
to
call
that
the
source.
A
L
A
And
that's
that's!
What
I'm
kind
of
struggling
with
is
cuz
ordinate
to
me
is
if
there
is
more
of
a
lower
level,
geeky
terms
like
the
origin
of
this
message
right
and
I'm
we're
trying
to
convey
something
bigger,
it's
a
least
to
me
anyway,
a
little
more
user
friendly
that
says:
hey
if
you're
trying
to
map
these
things
to
concept,
to
understand,
github
maps
to
what
origin
doesn't
jump
out
of
me
service
does.
L
A
Know
what,
if
we
do,
this
I
cuz
I
know
nothing
is
set
in
stone.
We
can
change.
These
things
later
is
service
horrible,
while
people
think
about
whether
origin
or
something
else
would
be
better
I'm
just
trying
to
get
away
from
the
the
P
word,
because
the
P
word
we
have
in
there
right
now,
I
think
is
incredibly
confusing.
I
were.
P
So
I
services,
potentially
the
right
word
services,
perhaps
the
most
overloaded
term
and
in
cloud
computing
so
like
that
would
be
my
only
caution
against
that.
I
think
I
personally
think
that
source
is
the
right
word
but
I.
You
know,
I
threw
that
bomb
out
last
week
that
I
think
cloud
events,
divine
service
wrongs
or.
P
P
A
Sure
you
are
and
now
keep
in
mind
I'll
get
to
you
Vinay
in
a
sec,
just
just
keep
in
mind
folks.
We
are
not
looking
for
the
perfect
word
at
this
point
in
time
we
are
looking
to
make
forward
progress
and
I
and
to
me
getting
away
from
the
P
word
is
forward
progress
at
this
point
in
time.
Not
that
service
is
gonna
be
set
in
stone.
Just
incremental
progress
is
I'm.
Looking
for
Vinay
I.
I
Just
add
to
the
jokes
anyway
and
key
word:
how
about
a
generous
service
is
very,
very
generic
right.
Everything
is.
A
services
has
been
commented
on,
but
generator
how
about
a
generator,
because,
as
a
consumer
I
mean
I,
think
that's
the
context
that
I'm
always
trying
to
address
these
things.
I,
really
don't
care
about
the
name,
but
I
need
the
context
and
how
about
a
generator,
I
need
to
know.
I
want
to
subscribe
to
these
this
class
of
generators
or
a
generator
or
generating
service.
Does
that
make
sense.
D
A
D
A
J
I
A
If
we
do
this
and
I
know
it's,
the
suggestion
is
obviously
very
biased,
because
my
PR
could
we
accept
source
now,
I'm,
sorry,
that's
source.
Can
we
accept
service
now
and
then
I'll
open
an
issue
to
start
gathering
alternatives
and
we
can
hash
through
an
issue
and
not
take
up
time
on
this
call,
and
then
you
can
throw
all
these
wonderful
joke
or
not
joke
names
into
the
issue
and
we'll
revisit
this
sounds
good
to
me.
Anybody
check
to
that
good.
A
K
B
A
K
D
A
Yeah
and
to
be
honest,
I,
don't
know
whether
I
did
a
good
or
bad
job.
I
did
try
to
define
service
up
here
with
it,
like
I
said
whether
it's
right
or
wrong,
don't
know,
but
that's
what
I
would
tend
to
do,
but
I
would
definitely
if
nothing
else
at
least
paste
this
text
into
the
issue,
and
if
you
want
to
wordsmith
that
as
well
go
for
it.
A
N
P
I
mean
the
big
thing
is
I
was
starting
sorry
like
thinking
about
the
entry
point
starting
from
from
both
ends.
So
there's
this
there's
a
scenario
of
I
want
to
view
a
list
of
services
right
I
might
want
events
from
or
man
I
got
the
event
type
that
I
want
I
want.
You
know
calm
that
example
that
storage,
where
can
I
get
that
from
and
if
we
don't
think
that
second
entry
point
is
a
valid
use
case.
Then
much
of
what
I,
specified
or
part
of
what
I
specified
could
be
dropped.
Yeah.
A
P
A
Where
is
it
something
like
this,
where
everything
specified
as
query
parameters,
so
service
equals
whatever
you're
searching
for
type
equals,
whatever
you're
searching
for
I?
Think
I
think
both
are
probably
technically
valid.
Let
me
go
ahead
and
state
my
biased
opinion.
First
I
kind
of
prefer
this,
because
I
think
this
gives
us
more
flexibility,
especially
if
we're
gonna
eventually
be
searching
on
other
things
like
protocol
and
stuff.
A
Whereas
it's
not
clear
to
me
whether
this
format
over
here
means
we
now
need
to
have
a
top
level
and
a
top
level
word
for
every
possible
thing,
you're
going
to
search
for,
because
that's
the
thing
that
people
care
most
about,
whereas
this
says
we
don't
care
what
you
what
you
as
a
user,
think
is
most
important.
Everything
is
just
a
query
parameter
but
Mike.
Maybe
you
want
to
chime
in
or
maybe
not,
maybe
not.
Okay,
obviously
notice.
Your
rough
muted
I
was
gonna.
Pick
on
you,
I
forgot
to
mute.
Okay.
A
Anybody
want
to
chime
in
in
terms
of
a
preference,
because
what
I
could
do
is
say
well,
pull
this
out
of
the
PR
and
only
talk
about
the
wordsmithing
stuff.
First
and
leave
this
for
a
second
PR.
That's
another
option
as
well
is
gonna
offer
that,
as
a
sort
of
a
compromise
to
work
to
split
the
to
jam,
your
hands
up,
you.
M
Can't
render
if
that
would
be
a
viable
approach.
I
think
that
would
be
an
incremental
change
for
you,
which
I
think
you
appreciate
and
I
I
guess
my
my
concern
I'm
still
sort
of
under
graph
to
our
side
of
the
fence
to
a
certain
extent,
but
the
trouble
with
some
of
these
is
that
they're
completely
unbounded
yeah.
M
So
as
soon
as
you
go
down
this
road,
you
need
to
include
pagination
and
a
whole
bunch
of
other
stuff
yeah,
because
I
may
not
have
any
idea
what
what
services
you
offer
or
what
events
are
available
and
that
this
would
be
extremely
big
and
also
I.
Guess
you
need
to
account
for
reg,
Xing
yeah,
so
I
might
know
that
Condor
example
great.
M
Is
it
an
event
family
but
I,
don't
know
any
of
the
types
underneath
so
I
don't
have
a
good
answer
to
this,
but
I
think
it's
I
think
it's
a
kind
of
worms
but
also
I
did
put
a
link
in
and
we've
used
our
SQL,
which
is
like
a
version
of
circle.
So
some
of
this
sort
of
restful,
query,
stuff
and
I-
don't
think
it
would
address
your
you
know.
M
A
If
you
want
to
do
something,
work
more
advanced
and
we
have
this
graph
QL
thing
as
a
as
an
as
an
optional
there
that
sits
on
top
right,
I,
wasn't
sure
where
we
wanted
to
go
with
that
yet.
But
it
seems
to
me
that
when
you
start
to
think
about
doing
anything
beyond
the
most
basic
thing
of
simple
word
searching,
it
seems
to
me
that
using
query
parameters
gives
you
the
most
flexibility.
K
P
A
P
A
G
Know
in
typical
rest,
the
service
would
be
singular
because
you've
picked
blob
service
and
types
would
be
singular
because
you've
picked
com
example
widget.
So
this
will
example.com
service
and
blob
blob
service
type
com
example
widget
and
the
types
is
the
the
way
you
know
how
to
make
a
query.
Yeah.
A
O
O
I
mean
the
notion
of
the
the
core
notion
of
rest
is
the
is
the
the
discoverability
right
which
I
think
Scott
and
like
we're
close
just
talking
about,
if
we're
just,
if
we're
just
trying
to
create
an
endpoint
over
HTTP,
where
we
want
to
allow
just,
you
know
completely
random
access
to
the
core
data,
I
think
that's
where
the
the
camp
that
says
we
should
just
go
to
straight
graph.
Ql
I
think
that's
part
of
where
they're
coming
from
right.
K
O
So
sort
of,
at
least
in
my
mind
in
this
discussion,
the
question
is
or
we
are
we
trying
to
put
structure
into
this
right
to
whatever
degree
of
generality,
we're
trying
to
get
on
the
clearing
side,
but
I
mean
rest.
Has
a
notion
of
I
mean
it
is
a
model
right
we're
creating
a
model
of
these.
These
restful
objects.
If
you
will
versus
here's,
a
sea
of
data
have
Havana
well
I.
Think
that's
the
more
fundamental
existential
question
here
so.
A
They
they
poke
on
you
a
little
there
John
to
elaborate,
because
I
think
everything
you
said
makes
a
lot
of
sense.
But
when
you
stick
with
the
end
there,
you
sort
talked
about
a
model
and
I
definitely
agree
with
that.
Would
this
type
of
line
then
violate
that
model,
because
the
model
probably
starts
with
services
up
top?
Not
types?
Do
you
think
this
is
violates
that
model,
or
do
you
think
it's
still
consistent?
Okay,.
O
O
Model
right
with
a
single
hierarchy:
that's
that
it's
better
to
think
of
those.
What
you're
calling
the
top
level
things
in
database
terms?
Think
of
it
more
like
materialized
views,
yep
right,
so
so
you
can
have
multiple
different
materialized
views
into
your
same
data.
Right.
Thank
you.
You
come
at
it
be
a
different
dimensionality
is
more.
A
O
Then
that
goes
back
to
the
rest
versus
graph
QL.
In
my
in
my
mind,
I
would
suggest
starting
off
with
you
know,
whatever
some
core
small
set
of
obvious
dimensions,
mm-hmm
and
and
see
how
limiting
or
not
limiting
that
is
to
people
and,
like
you,
you
mentioned
earlier
in
this
discussion,
I
mean
they.
You
know
if,
if
we're
going
to
do
this
thing
where
we
say
hey,
here's
this
base
base
approach
and
if
you
need
the
full
generality,
we
built
this
whatever,
whether
it's
optional
or
not,
graph
QL
chunk
on
top
that
you
can
use.
O
M
I
I
I
think
that's
a
good
approach,
yeah
and
and
then
you
would
say
you
know
list
me
all
the
services
and
then
you'd
have
a
filter
on
that,
for
the
pros
call,
I
mean
and
I
think
that's
probably
the
way
to
approach
that
is
just
try
and
pin
on
a
couple
of
routes
and
go
from
there
and
not
to
try
and
not
try
and
put
a
dimension
in
for
every
potential
thing.
You
might
want
a
filter
or
sort
on.
P
A
All
right
so
I'm
definitely
hearing
from
the
group
that
I
should
move
the
second
part
of
the
PR,
which
is
the
query
stuff
and
focused
just
on
the
word
smithing
and
provider
to
service
switch
any
just
any
counter
review
to
that.
Any
objection
to
heading
down
that
path,
okay,
I,
will
make
those
changes
given
we
are
nowhere
near
one
point,
though,
do
you
guys?
Are
you
guys
careful
with
me
making
that
change
of
ripping
out
that
second
part
of
the
PR
and
then
merging
it?
A
It
would
strictly
be
removing
stuff.
I
would
not
be
adding
anything
you're,
pretty
shifty
I,
don't
know,
I
was
trust
me
or
not.
If
you
feel
more
comfortable
you
can
do.
Is
this
I
will
make
the
changes
today
and
then
give
you
guys
until
end
of
day
Friday
before
I,
even
think
about
merging.
Has
that
or
I
can
wait.
I
honestly,
don't
care.
It's
not
like
this.
Is
that
urgent
I
just
trying
to
make
some
forward
progress
here,
because
I
know
we've
gone
several
weeks
without
any
pr's
being
merged.
A
Okay,
hey
what
aisle
I
want
to
be
aggressive,
so
it
like
what
I
like
to
do
is
I'll
make
the
changes.
I
promise
to
get
out
there
today
and
then
I'll
wait
until
Friday
to
let
people
have
a
quick
review
and
then
no
objection
by
the
end
of
Friday
I'll
merge
if
I
wait
till
Saturday
morning
or
something
okay.
A
E
A
A
A
A
A
A
A
A
K
So
so
so,
okay,
so
I'm
gonna
show
you
a
demo
which
shows
more
or
less
the
cup
of
belief,
system,
SDK
rust.
So
in
this
first
release
we
have,
of
course
most
of
the
PI's
are
considered
stable,
but
we
already
have
some
interesting
integrations,
so
we
have
the
basic
crater
crates
and
rust
are
like
modules
and
the
basic
create
provides
the
event.
K
Data
structure
provides
the
JSON,
even
format,
implementation,
and
what
really
matters
is
that
this
module
is
quite,
is
tested
with
a
new
loop,
see
web,
possibly
and
moves
it
to
chains,
and
then
we
have
implemented
integration
for
two
widely
use:
the
libraries
of
their
tactics
web
for
creating
web
servers
and
the
request
for
creating
over
quiet.
So.
K
H
A
K
So
one
demo,
it's
this
one
and
it's
a
demo
that
shows
a
web
server.
So
you
see
on
the
right
on
the
left
screen
the
code
of
the
server.
So
this
is
the
main
of
the
application.
The
main
of
the
application
is
done
with
optics
that
provides
a
little
local
rotation
and
I
have
I.
Have
I,
have
two
paths
on
one
path:
one
just
print
the
event
and
on
the
other
path,
I
replied
back
with
an
event.
The
other
part
of
the
demo.
K
Is
this
other
example-
and
this
is
a
really
interesting
example,
because
it
shows
how
the
cloud
event
as
decay
can
compile
it
to
webassembly.
So
this
is
that
HTML
of
the
page
is
just
a
form,
and
this
is
the
JavaScript
of
the
page
which
invokes
the
compiler,
the
web
assembly
module
and
then
using
some
jQuery
thing.
K
K
Where
we
go
to
okay,
we
see
the
form
I,
compile
the
phones
to
send
them
to
the
target
me
I
had
some
mock
data
and
myself
when
I
do
sound
on
the
other
side,
I
see
that
I
received
event
and
that's
pretty
much
everything.
Any
questions
cool
when
I
really
want
to
underline
here
is
that
the
module
compiled
assembly
compile
GBC
and
compile
it
moves
for
who
doesn't
know.
Musleh
most
is
a
micro
implementation
of
nipsey
and
allows
to
create
docker
images
of
the
size
of
9
mega.
A
Excellent,
any
questions,
alright
cool.
Thank
you
very
much
and
within
5
minutes
perfect.
Yes,
uh-huh!
All
right!
Let
me
see
if
I
can
share
something
again,
even
though
I
don't
think.
I'm
gonna
stay
here
very
long,
my
screen,
oh
there.
It
is
ok,
alright
quickly,
unfortunately,
I
don't
see,
grant
on
the
call
and
I
was
hoping
that
he
would
be,
but
Lance
you're
there,
but
I
was
kind
of
gonna
get
both
anyway.
So
I
know.
A
Last
time
we
talked
I
suppose
last
time
before
we
talked
about,
you
know
having
a
type,
a
type
script,
SDK
versus
JavaScript
SDK
and
we
needed
both
or
something
like
that.
And
since
then,
there's
been
lots
of
conversations
going
on
in
the
background
and
it
seems
like
we
may
have
come
to
a
fairly
good
resolution
where
it,
where
I
think
we're
going
to
try
to
work
to
support
both
typescript
and
JavaScript
within
the
JavaScript
SDK,
and
that's
all
goodness.
A
However,
what
wasn't
a
hundred
percent
clear
to
me
was
whether
that
meant
we
could
kill
the
typescript
SDK
or
whether
I
needed
to
stick
around
for,
for
other
reasons,
like
maybe
we
weren't
sure
whether
there's
this
miss
merging
is
gonna
happen
or
what
not
so
I
was
going
to
ask
him.
This
week's
call
whether
we
could
formally
kill
her
or
not,
but
obviously
since
grants
on
the
call-
and
he
was
the
main
proponent
for
the
separate
one
I'm,
not
sure
we
can
make
a
formal
decision.
A
I
will
then
reach
out
to
grant
and
get
his
perspective
on
it
and
if,
for
some
reason,
he
thinks
we
need
to
keep
it
around.
For
some
reason
we
could
talk
again
either
offline
or
on
this
call
next
week
to
see
why
he
thinks
we
need
it
and
whether
everybody
agrees
or
not-
but
at
least
it
does
seem
like
there
was
gonna
try
to
do
most
their
work
in
the
Java
SDK
I
mean
I,
know
pause
there
Lance.
Does
that
fairly?
Summarize
it
yeah.
E
A
Because
I
don't
want
to
do
something
that
he
that
you
know
I,
don't
want
misinterpret
his
comments.
So
does
anybody
on
the
call
think
we
need
to
keep
the
typescript
SDK
around
okay,
cool
I
will
reach
out
to
grant
and
see
where
his
thinking
at
is
on
this?
So
thank
you.
Everybody
all
right
now
to
the
main,
show
Hey
right.
It's
up
the
hour,
perfect,
okay,
trying
to
forget
the
best
way
to
approach
this
going
forward,
but
I'm
pom,
pom
pom.
A
So
let's
start
over
here
because
I
think,
like
you
added
a
comment
here,
I
guess
what
I'd
like
to
do
is:
have
you
sort
of
summarize
your
comment
here,
because
this
is
on
your
PR
and
then
see
what
kind
of
comments
that
brings
up
and
see
where
that
takes
us
in
terms
of
a
discussion?
Is
that
sound,
fair,
yep.
D
Okay,
so
basically
this
PR-
we
have
discussed
it
as
a
group
Cyril
weeks
ago,
actually
spent
about
an
hour.
They
just
of
this
PR
is
to
streamline
kind
of
simplify
the
cloud
event
interface
within
Java
SDK,
to
make
sure
that
it
stays
simple,
concise
and
represents
the
cloud
event
as
defined
by
the
specification
and
keeps
both
optional
functionality,
as
well
as
the
jewelry
functionality
out
of
it.
D
So
that's
kind
of
the
the
gist
of
this
PR.
However,
in
the
process
of
doing
this-
and
there
was
quite
a
number
of
disagreements
on
once-
those
auxilary
and
optional
operations
are
moved.
Where
are
they
moved
and
why
here
and
not
there
and
how
it
so
on
and
so
forth?
So
after
is
sort
of
reviewing
all
the
comments
and
some
of
the
thumbs-up
thumbs-down
and
other
and
responses,
it
actually
appears
to
us
that
there
is
really
not
a
whole
lot
of
disagreements
here.
D
Rather,
if
you
kind
of
look
at
them
separately,
and
so
this
comment
is
attempted
to
basically
outline
the
three
contentious
point.
The
three
contentious
points
that
I
believe
are
part
of
this
PR
and
basically
make
a
proposal
that
simply
states
that
okay,
we're
going
to
cancel
this
PR
and
instead
we're
going
to
open
three
different
issues
and
provide
three
different
PRS,
which
essentially
basically
kind
of
breaks
down
this
problem
into
three
individual
problems.
And
by
doing
so
you
know
we'll
all
we'll
get
to
the
same
sort
of
result,
but
we'll
get
there
gradually.
D
So
the
three
points
of
contentions
as
we
believe
they
are
the
Builder
methods
that
we
believe
should
that
should
be
consolidated
and
moved
into
kind
of
aversions
right
right
now,
I
moved
all
the
jewelry
functionality
into
a
single
generic.
You
know
catch-all
utility
class
with
exclusive
comment
that
we
can
address
it
later,
but
you
know
I'll
be
the
first
one
to
admit
that
sometimes
later
doesn't
come
and
it's
since
they're
forever.
D
So
fine
so
and
as
I
said
in
my
comment,
it
appears
to
be
actually
one
of
the
sources
of
agreement
that
has
more
suggested
to
have
a
merchant
builders
for
Builder
version.
One
ago,
the
perversion
to
and
kind
of
consolidate
all
those
methods
around
there
and
that
not
only
follows
some
of
the
best
some
of
the
typical
or
expected
Java
patterns.
It
also
provides
a
consistency
of
how
the
cloud
events
are
going
to
be
built.
D
Now
there
is
a
second
point
of
contention
is
the
encoding
operations,
which
is
basically
the
structure
to
binary
binary
to
structure
than
the
vice-versa?
So
again,
the
suggestion
was
that
I
believe
we
kind
of
can
get
all
behind
is
to
create
some
kind
of
a
encoder
utility
or
encoder
like
message
encoder
or
Claud
event.
D
Encoder,
we
can
argue
about
the
name
during
the
PR
discussion,
but
this
is
where
the
the
methods
which
do
the
structural
and
binary
will
get
moved
and
last
but
not
least,
and
I
believe
that's
the
least
contentious
point,
because
we
kind
of
agree
to
agree
on
it
on
the
very
first
call
after
Clemens
showed
how
they
did
it
in
c-sharp
is
decay
and
provided
some
justification
for
some
rural
use
cases.
Words
would
be
kind
of
important,
which
is
basically
provided
in
verbal
access
to
attributes,
not
just
access
to
individual
attributes.
D
A
D
A
I
can
send
them.
They
need
elaborate
a
little
bit
on
why
I'm
saying
that
when
I,
when
I
look
at
things
like
the
the
builders
stuff
and
obviously
correct
me,
if
I'm
getting
any
of
this
wrong
because
I'm
still
kind
of
speed,
but
it
seems
to
me
when
I
look
at
the
two
different
view
of
the
world.
When
you
guys
talk
about
using
a
builder
to
do
some
of
this
stuff
I.
What
I'm
hearing
from
from
Francesco
is.
We
may
not
necessarily
need
a
builder
interface
or
builder
class
to
do
it.
A
So
I'm
wondering
whether
there's
a
layered
approach
here
that
says,
if
the
native
way
to
talk
to
a
cloud
event
to
get
its
attributes
and
set
of
attributes,
it
works
for
you,
whether
that's
direct
getters
and
setters,
whether
it's
a
visitor
pattern
go
for
it.
But
but
let
me
just
finish
and
then
you
can
correct
me
where
I'm
yeah,
but
then,
if
you
want
something,
that's
maybe
a
simpler
user
experience.
A
D
D
It's
like
a
cable.
Are
we
going
to
call
them
builders
and
we
call
the
column
visitors?
Are
we
gonna
call
them
encoders
and
we're
gonna
call
them
whatever
fine?
We
can
have
this
discussion,
but
the
real
gist
of
this
PR
is
to
make
sure
that
the
cloud
event
stays
simple
stays.
Concise
represents
the
actual
cloud
event
as
a
defined
by
the
specification
and
operations
such
as
building
converting,
transforming
and
coding.
Reading
writing
are
implemented
in
the
appropriate
places,
but
those
places
are
not
the
cloud
event.
Interface.
A
D
I
it
sounds
fair
and
that
yeah,
so
that's
what
this
PR.
If
you
look
at
the
state
of
the
cloud
event
interface
in
this
VR,
then
with
the
with
the
addition
of
iterator
for
attributes
or
either
both
access
to
attributes,
that's
pretty
much!
You
click
on
the
actual!
Sorry,
because
you
look
at
the
diffs,
you.
K
D
O
Sorry,
sorry
for
a
semi
meta
question
is
given
that
we
have
support
for
multiple
languages.
You
there
is
there
some
discussion.
Is
there
some
I,
don't
know?
Maybe
consistency
or
similarity
in
terms
of
across
languages
right
is.
Does
that
help
doesn't?
Does
that
help
inform
some
of
these
I?
Don't
know
contentious
discussion
points.
That's.
D
A
great
point
and
to
answer
a
question
Clements
view
into
c-sharp
representation
of
clawed
event
had
a
heavy
influence
because
you
are
correct
at
some
point
of
time.
The
whole
point
of
Clawd
events
is
not
the
java
to
java
its
java
to
whatever
or
whatever,
to
Java
right
so
or
whatever
to
whatever.
So
we
need
to
make
sure
that,
once
the
cloud
event
is
sentient,
we
can
at
least
from
the
type
perspective.
That's
this
my
opinion.
D
We
should
at
least
have
some
consistency
and
without
even
knowing
the
language,
I
should
be
able
to
look
at
the
cloud
event.
Representation
in
go
or
in
c-sharp
and
say
yeah,
I
kind
of
understand,
looks
very
similar
or
looks
what
it's
supposed
to
look
like
looks
like
it's
defined
looks
the
way
is
defined
in
the
spec.
So,
yes,
okay,
it's
got
your.
G
Think
that
that's
the
whole
point
of
the
bindings
for
the
protocols
right.
That's
that's
the
interrupt
piece,
clemens
original
sdk
guidance
had
it
had
a
lot
of
a
lot
of
requirements
on
how
implement
ators
should
implement
and
the
trouble
is
it's
just
not
idiomatic,
first
different
languages,
because
what's
good
for
Java,
isn't
necessarily
what's
good
for
c-sharp
or
go
or
rust,
or
JavaScript,
and
people
that
come
to
these
languages
that
want
to
develop
in,
go
or
rust
or
JavaScript
need
to
program.
Idiomatically
I.
A
But
what
but,
let's
not
head
down
that
direction,
quite
yet:
okay,
so
okay!
So
when
I
look
at
this
I,
thank
you
Scott
for
the
comment,
though,
so
when
I
look
at
this,
my
general
sense
is
I.
Think
in
general,
people
are
okay
with
the
idea
of
well-defined
getters.
Now
there
may
be
a
question
of
whether
they're
immediately
on
the
cloud
event
or
whether
the
cloud
event
interface
extends
another
interface.
A
I
think
that's
a
stylistic
difference,
but
let's
assume
for
a
minute
that
one
way
or
another
everybody
you
you're
going
to
get
well-defined
getters
on
cloud
events,
either
directly
or
indirectly,
I
think
everybody's
in
agreement
with
that
in
general,
right,
okay,
so
I
think,
then
the
question
comes
around
the
the
mechanism
by
which
people
can
just
get
the
generic
attributes
thing
now.
Oh,
like
you,
said
that
the
with
missing
from
this
is
the
equivalent
of
but
get
extensions,
accept,
call
they
get
attributes
where
your
turn.
A
Replace
extensions
with
the
word
attributes
now,
as
I
understand
it.
There
are
two
patterns
at
play
here
or
and
and
therefore
two
differences
of
opinion.
One
is
what
you
just
described,
get
extension,
get
attributes
that
returns
a
map
versus
a
visitor
pattern
and
I
think
I
think
we
need
to
talk
about
those
two
patterns
because
again
my
limited.
My
limited
use
of
java
is
several
years
old
now,
but
I
believe
both
are
valid
patterns
in
terms
of
java
developers
may
use.
One
of
the
other
were
they're
both
perfectly
valid.
G
Is
your
hand,
up
my
hand,
is
up
again
okay.
So
this
the
get
extensions
method,
because
there
are
so
many
funky
restrictions
on
the
key
for
extensions
in
go.
We
decided
that
this
path
you
pass
in
the
key
that
you
would
like
to
get
the
extensions.
We
also
provide
this
method,
but
having
both
where
there's
a
key
accessor,
because
you
want
to
do
things
like
the
user.
Brings
you
a
key,
that's
maybe
invalid
or
a
camel
cased,
but
in
the
translation
to
a
protocol.
G
A
So
ask
Francesco
get
to
in
a
second
just
come
I'm
sure,
I
understand
this.
Guy
was
saying
so
I
understand
the
idea
of
passing
in
the
key
name
as
a
parameter.
I
get
that.
How
do
they
find
out
the
list
of
key
names
that
they
don't
know
that
in
advance?
You
also
offer
up
like
I,
get
key
names,
type
of
operation.
A
G
K
Well:
okay,
no
I
just
wanted
to
say
that
I
agree
with
having
bought
the
purchase.
There
is
no
problem
in
I
think
what
their
purchase
and
I
agree
and
also
agree
with
what
Scott
said
about
having
get
extension
and
then
more
than
returning
a
map.
Maybe
a
more
idiomatic
way.
Java
is
returning
the
key
set
so
get
accession,
Lee
getting
existential
names
and
get
extension
and
and
the
same
could
be
applied
to
get
attributes.
G
But
we
have
it
has
two
methods
and
I
think
if
I
were
to
do
it
again,
I
would
make
it
one
method
and
then
have
some
logic
internally
to
understand
what
what
like,
if
you
ask
for
data
scheme
at
a
certain
version
that
gets
remapped
to
like
the
correct
scheme,
key
for
example,
and
so
as
you
iterate
over
all
attributes
and
extension.
It
makes
note
difference
to
the
encoders.
Is.
K
A
G
No
I
would
actually
I
would
encourage
a
get
method
get
by
key
and
the
key
could
be
an
attribute
which
is
known
or
an
extension
which
is
in
this
bag.
Brian,
the
same
method
would
would
access
from
both
places
and
then
possibly
a
get
me
all
the
set
keys
so
that
I
can
go
and
iterate
over
them.
So
if
you
don't
have
you
know,
data
content,
type
or
data
schema
set?
It
wouldn't
return
that
key
for
this
event
right
what.
A
G
A
Right
I
think
we
all
agree.
We're
gonna.
Have
this
strongly
typed
getters
I,
don't
think
that's
a
question.
I
think
it's.
How
do
you
deal
with
sort
of
the
generic
get
her
kind
of
thing
like
this
get
extension
thing
right
and
I
think
what
you
were
saying
was:
if
you
had
to
do
it
over
again,
you
would
have
the
equivalent
of
a
get
attributes
which
returns
you.
A
G
D
You
know
you
don't
have
to
actually
agree
with
that
point
and
we
have
this
pattern
for
them
spring
as
well,
where
we
have
accessors.
So
in
other
words,
the
question
I
think
I
believe
what
is
being
discussed
right
now
is
what
should
be
exposed
through
the
core
cloud
event
interface
and
then
there's
additional
sort
of
column
decorators,
if
you
wish,
which
would
expose
additional
accessor
methods
that
would
target
specific
users
and.
A
G
G
G
D
J
D
J
Achieve
that
kind
of
layering
is
if
the,
if
the,
if
the
core
attributes
are
defined
in
an
interface
and
then
any
of
the
access,
any
set
of
extensions
can
actually
extend
that
interface.
So
the
implementation
type
extends
the
core
as
well,
and
then
you
get,
you
just
add
the
new
getters,
but
from
a
user's
perspective,
there's
a
single
type
that
gives
you
the
composition.
A
B
D
G
D
A
G
K
D
K
Could
be
eventually
problem
because
maybe
the
user
is
expecting
a
type?
Are
this
doing
a
dumb
call
diversion
the
touch
is
not
over?
Here
is
not
the
same
as
before,
and
it
gets
class
cast
exception,
yeah
I'm,
more
forgiving
an
object,
so
the
user
knows
that
it
needs
to
do
the
check
by
itself
doing
goodness
themself
the.
D
K
More
use
for
defensive
thing
towards
the
user,
so
the
user
can't
fail
can
make
it
work.
We
we
use
it.
We
usually
another,
are
used
in
another
project
to
return
things
from
generic
map
like
that,
because
you
can
get
returning
T
and
most
of
these
so
I'm
multiple
keeping
object
or
having
just
an
extension
of
object.
A
H
A
This
right
get
attributes
cuz,
I,
I'm,
I'm,
I'm,
okay,
not
being
a
Java
guy
anymore,
I'm
fascinated
that
this
one
is
generic.
You
can
go
over
spec
to
find
attributes
as
well
as
extensions,
but
then
we
split
them
out
here
and
I'm
wondering.
Would
we
not
offer
up
a
one
that
gets
everything
all
at
once?
I
think.
D
The
scouts
point
it's
more
of
how
like,
if
I,
look
at
the
cloud
event
and
read
the
spec
and
there's
a
there's,
a
exclusive
points
about
extensions
and
attributes
and
I
can
see
them
and
I
can
retrieve
them
as
such,
but
then,
as
a
convenience
for
developer,
you
have
additional
sort
of
getters
like
the
one
on
line.
Six,
for
example,
that
will
allow
you
to
make
the
Javadoc
will
specify
that
it
will
actually
give
you
either
one
right.
So
it's
more
like
we
need
to
line
five
and
line.
D
B
A
G
K
K
What
happened
when
you
see
realize
the
JSON
and
you
read
from
you're
deciding
if,
when
you
see
realized
to
JSON,
you
had
an
extension
at
the
time
and
on
the
other
side,
when
you
read
it,
the
disorientation
process
won't
recognize
that
that's
time.
So
when
you
read
it,
you
maybe
you're
expecting
a
time,
but
in
fact
you
you
will
get
a
string.
K
A
D
G
The
interface
right
there,
yeah
right,
I,
I,
think
the
thing
that's
missing
and
that
I
think
the
thing
that
would
make
slinky
happy
putting
words
in
his
mouth.
Yes,
please,
there
are,
we
need
to
take
out
just
take
a
pass
at
making
the
interfaces
for
each
persona
that
we
are
trying
to
target
and
the
there's
one
for
the
encoders
and
decoders
and
there's
one
for
the
consumers.
There's
probably
one
for
the
producers,
no
objection
here.
So
the
producer
interface
is
full
of
the
setter
methods
which
could
be
implemented
by
a
builder.
G
The
the
accessor
methods
is
what
we're
talking
about
right
here.
I
question:
if
get
attributes
is
useful
for
an
end
consumer
but
I,
add
I,
don't
really
have
a
problem
with
it.
It's
really
useful
for
an
encoder,
so
the
get
extensions
and
get
attributes
for
an
encoder
is
makes
the
job
very
generic.
That's
nice.
G
K
K
K
Of
course,
what
I
proposing
the
PR
and
I
think
you
people
I
really
look
at
it?
Is
that
I
I'm
giving
the
photo
implementation
for
this
visit
process
so
who
implements
the
third
part
implementer
for
the
cloud
event.
Interface
done.
Don't
need
to
care
at
all
about
that,
because
it's
already
given
to
you
by
these.
D
Implementations,
the
problem
with
bringing
this
implementation,
whether
I
want
it
or
not,
is
that
sooner
or
later
they
bring
additional
obstruction,
additional
dependencies
on
the
class
path
and
so
on
and
so
forth,
where
all
I
care
about-
and
we
already
discussed
that
sort
of
many
times
over,
that
I
might
just
care.
I
may
only
care
about
cloud
event,
type
for
inner
process,
the
communication
between
methods
between
operations
and
so
on.
So
yes,
you
can.
We
can
have
a
visitor.
D
We
can
have
many
different
specializations
as
Ascot
sort
of
points
out
right
now,
but
it's
the
implementation
that
should
say:
okay,
cloud
event,
implementation,
it
implements
cloud
event,
cloud
event,
access
or
quad
event
visit
or
cloud
event.
This
cloud
event
that
that's
fine,
it's
perfectly
fine,
but
when
the
core
interface
extends
from
another
interface,
it's
as
if
the
core
interface
and
that
other
interface
on
same
thing,
our
merchants
won.
G
J
Way,
I
look
at
this
this
the
simplest
implementation
that
the
simplest
use
case
should
be
met
by
the
by
the
bottom
most
layer
and
the
simplest
use
case.
I
think
is
a
function,
that's
receiving
a
cloud
of
it
and
calling
getters
and
nothing
else,
and
and
so
the
core
interface
should
only
meet
that
need,
and
then
builders
and
encoders
and
any
visitor
can
be
layered.
On
top
of
that,
for
other
types
of
these
cases
correct.
G
A
K
D
G
D
K
I
am
just
question
for
you.
What
should
be
SDK
does
what
she
D
is
decayed
up.
What
should
be
s?
Disease
do
when
I
need
a
code
even
Twitter,
but
because,
for
example,
I
need
to
implement
are
even
former
to
implement
a
protocol
binding,
but
the
code
event
that
you
provide
to
me
doesn't
implement
the
code
even
Twitter.
It.
D
Doesn't
have
to
you
can
have
we're
not
against
readers
and
what
we're
saying
about
cloud
event,
reader
and
writer
interfaces.
This
is
just
debating
right
now
we
there's
a
separate
discussion
about
and
we
look.
You
know
in
a
in
a
proposal
that
of
lying
in
a
less
comment
on
the
PR,
we
kind
of
alluded
what
what
it
could
be
because
we
already
have
builders.
We
can
extend
upon
that.
We
already
have
the
concept
of
encoders.
We
can
expand
on
that,
so,
in
other
words,
there
are
just
like.
In
Java
we
have
infiltrators
input
writers.
D
There
are
separate
their
strategies,
their
separate
interfaces.
There
are
separate
classes
out
there
so
and
for
different,
providing
you
with
a
different
reading
and
writing
strategies
for
English
streams
for
files
for
this.
For
that
so
the
same
thing
here,
we
don't
have
to
kind
of
reinvent
the
wheel.
So
you
give
me
data
and
now
I
have
a
whole
toolbox
which
allows
me
to
deal
with
this
data.
Either
transfer
convert
it
from
one
presentation
to
another:
write
it
to
a
file.
Send
it
over
socket
do
all
kinds
of
different
things.
K
But
I
don't
do
this
with
your
question
yeah
your
answer,
I
mean
well
yeah
I
need
I
need,
let's
say:
I
need
to
implement
an
even
format.
Okay,
I
expect
by
the
interface
a
cloud
even
Twitter,
because
I
need
something
that
allows
me
to
access
us
in
your
software
manner
to
the
event
with
less
already
possible.
So
I.
G
K
G
Might
have,
of
course,
how
important
you
use
these
interfaces
to
separate
the
concerns
inside
of
the
implementation.
So
if,
if
that
function,
is
that
that's
consuming
the
cloud
event?
Is
it's
only?
It's
only
asking
to
be
a
cloud
event.
Reader
or
maybe
maybe
the
problem
is
that
the
interface
cloud
event
is,
is
untrue
and
there's
an
only
an
implementation,
that's
called
cloud
event
and
it
implements
reader
and
writer.
D
But
also
I'm,
still
struggling
to
understand,
I
have
an
object
representing
a
data.
Reading
writing
transforming
converting
is
a
whole
separate
concern.
Just
like
we
have
in
pure
Java.
We
have
a
data
and
we're
writing
it
to
a
file
so
I'm
going
to
go
and
grab
a
input,
stream,
writer
or
industry
reader
and
so
on
and
and
deal
with
that.
So
why
I
don't
expect
the
file
to
sort
of
write
or
read
itself?
D
Why
should
I
expect
maybe
I'm
missing
something
bigger
here,
but
why
cloud
event
all
of
a
sudden
must
have
a
reader
cloud
event
represents
the
event
and
it
contains
accessors
for
all
the
attributes.
For
me
to
literally
make
anything
out
of
it
to
convert
it,
to
transform
it
into
any
kind
of
representational
form.
I
can
possibly
do
I.
K
J
K
Whatever
implementation-
because
you
came
here
except
me
because
you
wanted
to
implement
the
cloud
event
in
play
interface
in
another
package-
which
is
fine-
so
what
I'm?
What
I'm
trying
to
say,
you
is
okay,
that's
that's
good,
but
we
need
to
make
sure
that
whatever
implement
issue
you
create
works
well
with
the
other
parts
of
the
SDK.
Otherwise
we
are
crazy.
We
are
petitioning
to
using
a
bad
behavior,
something
that
can
blow
up.
A
K
A
I
want
to
make
sure
I
understand
it.
Something
would
blow
up
because
well
because
Scott
you
mention
compile
time
and
I,
think
that's
the
one
that
that's
jumped
out
of
me.
First
right,
if
I
am
writing
code
that
just
talks
to
a
cloud
events.
Okay,
all
I
know
is
the
interface
or
all
I
see
is
that
interface
on
line
one
through
nine
and
I
have
a
class
file
that
goes
along
with
that.
That
knows
how
to
process
that
that
structure,
if
I,
if
my
code
wants
to
then
do
some
additional
processing.
A
On
top
of
that
with
you
guys
calling
the
readers
and
writers
then,
first
of
all,
yes,
my
code
needs
to
import
the
proper
library
right
to
have
that
new
functionality
or
the
new
interface
defined.
So
that
needs
to
be
in
my
class
path
right
there
at
compile
time
and
then
at
runtime.
I
need
to
make
sure
that
I
have
the
right
jar
file,
but
has
that
class
for
that
interface
defined?
Do
I
have
that
right.
D
K
K
D
First
of
all,
it's
again,
it's
a
very
common
pattern
to
change
representation
of
one
thing
to
another
and
if
I
have
a
method
that
takes,
for
example,
cloud
event,
writer
and
all
I
have
is
the
reference
to
cloud
event
itself,
which
is
which
may
or
may
not
be
a
writer.
There
are
patterns
and
their
utility
classes
that
allows
us
to
actually
say.
Listen.
Let
me
convert
this
if
necessary,
or
if
it's
already
a
cloud
event.
D
Writer,
then
I'm
going
to
give
you
exactly
what
it
is,
how
their
words
basically
be
a
little
more
defensive
as
you
as
you
use
right.
So
that's
point
number
one.
So,
in
other
words,
just
be
yeah,
okay,
so,
but
just
because
so
that's
point
number
one
point
number
two
he's
looking
about
protocol
bindings.
Here's
another
example.
So,
while
as
like,
for
example,
we
currently
have
quite
a
number
of
bindings
already.
D
Number
of
years
for
rabbit
zones
with
for
many
different
things
right
so,
for
example,
within
a
particular
scope
of
let's
say
spring
Clause
stream.
I
want
a
Red
Cloud
event:
Kafka
I
already
have
bindings
I,
don't
have
to
write
a
single
line
of
code
for
that
right.
So
for
me,
it's
just
a
matter
of
converting
it
to
a
proper
binding
representation,
so
in
other
words,
they're
still
gonna
be
some
custom
within
framework
within
application
code.
D
That
would
they
need
to
operate
on
that
Claud
event
and
maybe
come
up
with
a
custom
structures
and
so
on
and
so
forth.
But
it's
the
core
is
this
origin
of
the
representational
object,
which
is
at
the
heart
of
the
entire
effort,
which
is
clouded
event,
which
is
what
we're
simply
simply
saying
that
should
be
simple.
So
any
of
these
possible
combinations
that
evolved
through
typical
enterprise-e
development
are
not
just
possible
but
are
also
simple
to
achieve.
A
K
A
K
Our
first
point,
one
I,
would
say
that
that's
what
you
did
in
your
PR
and
you
did
it
with
a
huge
and
pretty
bad
copy.
Honestly,
because
that's
really
where
the
problem
is,
is
that
if
you
don't,
if
the
implementation
doesn't
support
code
event
Twitter,
then
you
need
to
copy
the
data
somewhere.
This
is
potentially
a
huge
waste
of
memory.
Happy.
D
K
K
E
A
A
E
G
K
You're
so
you're
saying
that
cloud
event
input,
sorry
that
so
you
say
that
code
event
am
play
shoe
that
cloud
even
Twitter,
which
contains
the
visitor
and
then
it
implements
cloudy
event,
attributes
which
contains
together
for
the
type
in
attributes
and
then
it
contains,
and
then
it
implements
get
extensions.
That's.
G
G
I
well,
so
my
interpretation
is
that
people
tend
to
want
to
think
about
cloud
event
as
cloud
event.
Writer,
a
reader
interface
and
because
of
like
the
common
use
case,
is
going
to
be
the
the
function
that
gets
invoked
and
it
wants
to
get
passed
down
a
cloud
event
right.
So
we
want
to
make
people
feel
comfortable
about
that.
But
what
we
actually
call
that
thing
is
cloud
event
reader,
because
it
has
all
the
accessories
that
could
be
a
so.
G
G
J
I
mean
I
think
it's
more
common,
that
the
the
core
interface
is
beginners
and
except
in
special
cases,
where
you're
defining
an
interface
for
something
like
a
factory
right
that
then
you
may
have
centers,
but
typically
getters
are
on
the
interface
and
then
there's
a
builder
that
generates
instances
that
implement
that
interface.
And
that's
where
you
have
write
efforts.
J
K
Program
is
that
I
think
I
mean
it's.
It's
not
I.
Think.
Is
that
more
something
that
we
try
is
that,
having
some
using
gate
attributes,
it
could
be
potentially
more
costly
because
you
are
going
you're
gonna
allocate
a
map
on
the
out
path,
which
is
something
we
we
can
easily
avoid
using
the
restore
pattern.
So
again,
what
I'm
saying
is
that
you
should
try
to
see
this
interface
on
so
far
from
the
perspective
of
implementing
protocol
bindings
and
even
formats.
G
D
A
G
K
For
what
regards
the
for
the
spectra
version?
Sorry,
then
it
could
be
useful
to
access
directly
to
respect
version
for
what
your
guys
implementing
different
formats.
For
example,
when
you,
when
you
are
implementing
the
even
format
for
JSON,
you
wanna,
know
a
question
because
you
need,
but
at
this
point
that
thing's
already.
G
G
G
K
A
D
Discuss
point
is
I
mean
this
is
the
one.
We
should
concentrate
it's
not
about
what's
wrong
with
the
visitor
pattern,
it's
really
more
about
much
higher
point,
which
is
we
have
personas.
We
have
flavors
right
and
I
only
care
about
than
just
a
view
of
it
or
I,
or
he
he
only
cares
about
how
to
read
or
write
with
glaucoma.
So
in
other
words,
this
is
again
a
very
idiomatic
and
a
very
common
approach
in
Java
to
look
at
the
same
thing
through
a
different
type
of
glasses.
So
it's
not
a
matter
of
opinion.
D
G
J
A
Okay,
so
okay,
we're
almost
out
of
time
I'd
like
to
make
a
recommendation
here,
I
think
a
lot
of
good
things
have
been
said.
I
think
we
actually
did
make
some
progress,
some
not
a
whole
lot,
but
some
would
people
be
willing
to
have
another
phone
call.
I
know
I'm
gonna,
forgive
me
for
to
the
Europe
friends
tomorrow.
If
not
Monday
I
know
that
screws
over
the
US
guys,
but
you're
gonna
screw
over
the
Rio
up
guys
today,
which
probably
screw
over
the
u.s.
guys.
A
D
D
D
Seem
to
agree
on
like
like
again
the
three
of
us
who
commented,
but
you
know
Francesca
keep
it's
a
keeps
insisting
on
a
specific
sort
of
approach
and
we
need
to
mean
to
kind
of
move
on.
Otherwise
we're
going
to
be
like
answering
the
questions
what's
wrong
with
visitorís
pattern,
where
it's
not
a
question
of
a
visitor
pattern
and
there's
nothing
wrong
with
it.
It's
really
the
question
of.
Do
we
agree
that
the
interfaces
should
be
idiomatic,
simple
and
layered,
as
we
all
seem
to
be
talking
about
the
same
thing?
D
The
word
escapes
me,
but
other
sort
of
flavors
that
are
specific
to
and
I'm
going
to
use,
Gosforth
personas
that
and
if
you
cannot
produce
that
particular
interface,
then
that's
your
problem
right,
but
a
you
know,
don't
bring
me
any
kind
of
default
that
might
bite
me
in
the
long
run,
because
that's
not
because
that
might
bring
some
other
dependency.
That
I
may
not
be
interested.
No
I
think.
A
Ok,
so
ok
I'd,
like
like
all
sides
to
have
some
time
to
to
coffin
and
think
some
more
about
this,
but
I
think
the
problem
is
it's
kind
of
what
you
what
you
said
there
in
terms
of
okay?
Are
we
gonna,
have
sort
of
the
alert
approach,
or
is
there
going
to
be
a
default
implementation
of
Reader
for
lack
of
a
better
phrase?
I
think
that's
the
root
of
it
and
like
to
continue
the
discussion
tomorrow.
Are
you
guys
available
at
the
same
time,
tomorrow
noon,
eastern.