►
From YouTube: CNCF Serverless WG Meeting - 2019-07-18
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
Alright,
not
hearing
any
I
think
technically
on
our
calendars.
There
may
be
an
SDK
call
scheduled
for
today,
but
I
think
some
people
are
traveling
and
I
know.
Clemens
is
on
vacation,
so
I'm
going
to
end
up
canceling
that
call.
Unless
someone
really
really
wants
it,
but
I
don't
think
there's
anything
really
big
to
discuss
other
than
Clemens
is
PR,
which
I
believe
Scott
had
an
AI
for,
but
he
hasn't
it
just
do
it
yet.
So
there's
nothing
really
to
discuss
there.
A
So
I
was
gonna,
cancel
that
meeting
in
case
you
guys
were
thinking
about
joining
incubator,
I'm
still
waiting
for
three
end
users.
I
know
some
people
in
the
previous
call
mentioned
that
they
were
going
to
try
to
get
me
some
just
an
Ag
reminder
to
do
that
when
you
guys
get
a
chance
and
of
course,
please
review
the
proposal
itself
to
see
if
you
guys
think
that
the
text
in
there
is
says
everything
appropriately
I.
A
So
if
you
guys
can
look
over
the
description
about
why
we
do
things
differently
there,
if
you
think
that
sounds
good
or
if
you
think
we
need
to
change
the
description
in
there,
you
know,
please
let
me
know,
let's
move
forward,
let's
just
jump
into
peer
review.
First
things
first.
Hopefully
this
is
an
easy
one.
This
was
technically
noticed
by
gem
I.
Think
it's
just
an
oversight.
Since
we
remove
the
extensions
bag
itself,
the
specs
on
JSON
schema
still
mentions
it.
A
B
A
B
C
A
Did
say
that
but
I'll
double
check
because
I.
D
C
Comments
and
json
schema
no
there's,
there's
a
construct
where
you
can
allow
additional
properties,
I-I-I
I'm,
fine,
with
the
change,
although
obviously
hug
it.
It
must
have
happened
before
my
mind
time
on
this
project,
but
I'll
I'll
check
with
the
correct
yeah.
If
there's
any
additional
syntax.
Okay.
A
C
Sure,
okay,
so
this
is
all
related
to
the
issue
evan
had
raised
with.
If
we
have
maps
of
maps,
then
you
can
go
down
a
rabbit,
hole
trying
to
encode
or
decode
those
and
I
think
his
proposal
was
to
say:
let's
do
away
with
the
map
construct.
So
what
I
started
to
really
sort
of
have
thoughts
about
was
how
that
applies
to
extensions
that
actually
have
multiple
attributes
or
properties
associated
with
them.
So
in
that
example
we're
looking
at
there.
C
This
is
a
structured
event
that
you
know
assuming
we've
taken
on
Doug's
recent
PR
change.
The
extensions
are
modeled
at
the
top
level.
Yes,
I
have
a
bag
of
extensions
for
the
sequence
and
a
bag
of
extensions
for
a
proprietary
one
called
BBS
that
that
no
one
has
any
knowledge
of
it,
except
the
people
that
deal
with
that.
So
now
comes
the
test.
Yeah,
okay,
I
want
to
take
that
structured
mode,
structured
content
and
re
encode
it
into
binary
now
I've
left
fill
in
the
blanks
there,
because
you
know
I
would
propose
doing
it.
C
A
Correct
me,
if
I'm
wrong,
but
I
believe
that
the
current
spec
says
that
this
sequence,
block
right
here
would
get
see,
relies
as
a
shippi
headers
in
the
format
of
c
e
sequence,
that
sequence,
:
99,
you
have
c
e
sequence,
does
sequence
type
:,
integer,
yes,
and
then
that's
and
then
you
should
be
able
to
do
the
exact
opposite
for
your
for
your
step,
3
right!
Yes,.
C
C
And
these
to
become
tab,
little
things
right
and
so
now
you've
lost
any
sort
of
encapsulation
for
those
extensions
and
also
and
I.
Think,
though
this
was
what
I
was
trying
to
get
at
in
my
slacking
on
the
phone
was
that
the
SDKs,
as
they're
written
today
honor
this
sort
of
notion
of
an
extension
that
has
a
set
of
attributes
and
that
there
can
be
multiple
extensions
within
a
cloud
event.
C
E
C
A
Make
sure
I
understand
what
your
concern
is,
because
it's
something
it
could
be
one
of
two
things
it
at
a
top
level.
It
sounds
like
you
agree
that
you
can't
technically
serialize
things
back
and
forth
and
go
between
the
binary
and
structured
hey
where
things
at
the
top
level.
It's
you're
more
concerned
with
this.
The
the
semantic
grouping
of
things
do
I.
Have
that
right.
Well,
I
mean
I
with.
C
A
If
you
did
you'd
be
readapted
evans
proposal,
this
sequence
would
go
away.
These
would
remain
it's
tough
little
things
the
BBS
would
go
away.
These
would
be
top
of
all
things,
but
the
ISIS
I
suspect
the
recommendation
would
be
well.
These
aren't
really
descriptive
enough.
You
may
want
to
put
the
word
BBS
in
front
of
both
of
these
as
they
as
they
become
top-level
things
right.
A
C
A
C
E
C
I,
be
always
misled
by
the
fact
that
the
spec
Jason
fire
was
had
not
been
updated.
Since
you
know,
a
previous
decision
had
been
made,
but
I'd
always
naturally
assumed
that
they
were
grouped
yeah
and
when
I
looked
at
the
SDKs,
the
SDK
writers
appeared
to
have
gone
down
the
same
road
yeah.
They
were
offering
the
ability
to
add
an
extension
and
an
extension
and
I
think
even
in
the
c-sharp
news
case,
I'm,
not
a
c-sharp
expert.
C
C
A
Well,
yeah,
but
so
I
believe
what
this
actually
says
here,
though,
is
there
was
a
top-level
property
called
extensions
yeah.
Basically,
as
we
called
in
the
past,
a
bag
and
inside
of
that
bag
could
basically
be
anything.
It
could
be
a
list
of
name
value
pairs
or
give
you
a
list
of
named
:
objects
right,
you
guys,
they
said
you
could
have
bags
inside
bags
right,
but
I'd
also
could
just
be
a
flat
list
of
top-level
things.
A
I
think
that
word
is
somewhere
in
one
of
the
extensions
but
yeah
you
seem
to
be
cleaning
that,
basically,
all
extensions
are
themselves
bags
with
multiple
properties
on
Nathe
and
I.
Don't
believe.
That's
true
extensions,
as
of
today
can
be
bags,
but
they
can
also
be
just
single
name
value
pairs
right.
A
Write
because,
because
what
you're
asking
for
we're
asking
about
you
know
that
magic
happens
right
where
somebody's
says,
if
they
see
BBS
context
and
then
BBS
correlation,
if
you're
asking
the
SDK
writer
to
convert
that
from
a
list
of
top-level
things
into
a
bag
called
BBS
and
VM,
removing
the
prefix
from
those
two
things
I'll
be
blown
away.
If
any
SDK
actually
does
that,
because
that
seems
like
a
little
bit
too
much
magic
and
in
reading
those
lines,
that's.
C
So
we
know
we're
saying:
let's
take
the
dash
out,
whereas
wall
I'm
saying
is,
you
know,
let's
leave
it
in,
but
just
limit
extensions
to
one
level
yeah.
So
you
don't
have
a
map
of
a
map
of
a
map.
Guys
just
make
sure
you
aren't
it.
You
can
still
have
a
top
level
single.
You
know
an
extension
with
a
single
primitive
doesn't
always
have
to
be
a
bag,
but
yeah
I,
I,
don't
know
how
else
to
explain.
C
A
And
be,
are
you
clear,
I'm,
not
necessarily
a
position
where
the
other
I'm
just
trying
to
make
sure
they
were
on
the
same
page,
because
I
still
think
there's
a
little
bit
of
a
misunderstanding
in
the
sense
that
my
understanding
of
Evans
proposal
is
that
if
everything
gets
fun
to
the
top-level
SDK
writers
would
not
try
to
do
that?
Mapping
that
you're
talking
about
they
would
not
try
to
do
that
correlation.
If.
C
A
C
A
C
C
The
same
issue
you
have
where
you
want
issued
in
the
same
way
that
HTTP
is
just
you
know
a
payload
and
set
of
headers
and
I'd
sort
of
imagined
the
way
you
guys
had
sort
of
come
at.
This
was
just
a
more
structured
than
that.
That
was
all
you
know
to
allow
that
sort
of
I'm
automatically
namespacing
my
extensions
by
like
putting
it
in
a
BBS
yo
placeholder
yeah
in
this
instance
yeah.
A
So
I,
don't
we've
tell
me
the
conversation
I'd
like
to
hear
from
other
people
on
the
call.
What,
if
you
guys
been
thinking
of
relative
to
this
issue,
I
think
technically
from
a
straight
coding
perspective,
we
could
make
either
one
technically
work.
I,
think
a
lot
of
it
does
come
down
to
human
readability
or
wrapping
around
around
head
around
things.
You
know
good,
obviously,
having
a
grouping
like
this
is
much
easier
to
for
people
to
wrap
their
head
around,
because
they
feel
like
there's
a
security
blanket
of
some
sort
of
uniqueness.
A
By
putting
this
here,
but
technically
you
can
always
prefix
these
things
after
top-level
things,
right
so
because
more
of
a
human
readable
thing
in
my
mind,
but
it
that
I
don't
want
to
say
discount
that
Oh
either,
because
sometimes
that
doesn't
matter
in
terms
of
usability
and
people's
perception
of
usability
of
the
spec.
So
what
are
the
whatever
got?
The
people
been
thinking
about
this
issue.
F
Thank
you,
I'm
concerned.
If
we
flattened
I,
said
and
I
can
see
something
like
sequence,
their
sequence,
if
I
recall
correctly,
the
limit
for
the
keys
is
20,
so
that
basically
means
you
have
thank
Eric
tears
for
one
and
ten
characters
for
two
for
the
second,
in
my
experience
we
often
see
there
are
some
applications
and
their
identifier
will
be
longer,
so
I'm
afraid
you'll
get
in
the
situation
will
be
stuck
on
or
shortening
and
consenting
condensing
skipping
wall
walls
and
stuff,
like
that.
So
we'll
end
every
kind
of
less
usable
code
for
the
developers.
A
B
B
A
G
I
was
I
was
confused,
why
the
sequence
that
sequence,
thing
and
sequence-
the
sequence
type-
is
something
that's
not
gonna
work
at
that,
because
that
is
both
that's
easily
understandable
by
machines
and
I.
Definitely
as
an
SDK
user.
I
definitely
want
to
be
able
to
do
sequence
that
sequence,
so
I
don't
understand.
Why
is
this
missile
was
the
issue
in
that
you
please.
G
D
G
A
You're
this
PR
Evan
is
suggesting
that
we
don't
allow
Maps
at
all
so
that,
if
someone
wanted
to
represent
this
after
this
PR
is
merged,
they
would
either
take
these
as
his
properties
as
they
currently
exist
and
make
them
top
level
things
or
in
the
case
down
here.
If
these
names
are
too
generic,
they
would
prefix
them
with
BBS.
That's
all
I
was
saying.
E
A
E
I
I
I'm
negative
on
the
proposal.
I
think
that
namespacing
and
then
you're
gonna
get
something
that's
complicated,
whether
you
put
it
in
JSON
or
put
up
laughs
or
whatever.
Just
you
know,
if
somebody
wants
to
have
a
structured
value
for
an
extension
I'm
fine
with
that
and
the
the
problem
that
presents
is
not
that
big
in
the
solutions
I
think
are
uglier
over.
A
A
E
A
A
Okay,
cuz
cuz,
to
be
honest,
I-I've
I
have
wondered
that
myself.
I've
wondered
whether
yes
from
a
pure
technical
perspective,
someone
could
produce
maps
three
little
deep
and
then
it's
gonna
maybe
cause
some
sort
of
problems,
but
just
because
the
spec
allows
that
doesn't
mean
it's
necessary
smart
people
to
do
it
and
they'll
quickly
learn
to
not
to
do
stupid
things.
C
So
maybe
that
maybe
that's
the
point
that
we
try
and
say
something
reminds
of
you
know
you
shouldn't
have
nesting
of
more
than
you
know:
n
levels
yeah,
whatever
Enys,
you
know
if
it's
one
or
two
or
whatever,
and
oh
you
guarantee
that
everything
will
work
up
to
that
level.
And
beyond
that
you
know
your
your
rate
of
success
is
invariant
I'd.
C
Again,
we're
gonna
have
to
you
know:
I
do
have
Scots
on
the
line,
but
we
there's
got
to
be
some
guidance
as
to
what
those
SDK
writers
are
gonna
have
to
expect
to
deal
with
yeah
and
I.
Think
that's
where
ever
was
coming
from
yeah
as
he
started
to
write
code
around
these
things.
He
was
coming
up
against
this.
You
know
how
far
do
I
go
statement.
A
A
G
C
And
I
think
that's
the
I
think
that's
the
point.
I
think
that
if
I
understand
it
correctly,
I
think
the
binding
rules
we
have
today
actually
will
work
it's
just
because
it's
sort
of
recursive
there
were
concerns
that
you
could
end
up
with
maps
with
maps
of
maps
of
maps
of
maps
and
you
would
really
go
down
a
rabbit,
hole
yeah.
A
I
think
I'm
try
to
remember
everything
cause
if
it
wasn't
effects.
We
looked
through
like
460
and
456,
but
I
think
I,
don't
think,
there's
anything
technically
wrong
with
the
spec
I
think
it
was
just
as
Evans
said
there.
It's
just
things,
get
problematic
and
ugly
is
I,
think
what
it
comes
down
to,
and
so
he
was
suggesting
to
keep
life
easy
by
trying
to
limit
things.
I
think
that's
what
I
hear.
A
I
C
I
think
that's
where
you
would
follow
a
similar
scenario
to
the
HCP
binding
yeah,
where
you
would
you
sort
of
fake
the
map
through
the
property,
names
and
I,
must
admit,
I
thought
that
was
probably
what
would
be
going
on.
There
was
the
other
one
Doug
I'm,
not
sure.
If
this
is
also
related
to
another
issue
around
the
fact
of
you
know,
if
you
have
any
x'
or
maps
of
Enys,
then
you
know
how
do
you
transport
light
in
or
timestamps
when
you
know
your
transport
binding
doesn't
even
have
that
construct.
C
A
A
I
Problem
was
addressed
by
Clemens,
with
the
everything
has
a
string,
encoding
and
the
it's
the
responsibility
of
the
client
receiving
the
message
to
reconstruct
the
types
if
the
transport
didn't
support
the
actual
types
and
their
strings.
So
the
client
should
know
what
side
your
attributes
are
because
well,
it
should
know
they're
either
cloud
events,
attributes
or
extension
attributes.
If
it
doesn't
understand
them,
it'll
leave
them
as
strings
and
when
someone
does
understand
them,
they
can
take
over
the
string.
It's
here.
Okay,
it's
Nigel.
A
A
I
B
A
I
A
A
Okay,
anybody
else
want
to
speak
one
way
or
the
other
run
this
one.
A
Okay,
cuz
I
have
a
feeling.
If
this
may
just
come
down
to
a
very
binary
choice,
you
know
maps
are
no
Maps
basically
and
then,
once
that
decision
is
made,
we
just
need
to
decide
what
the
ramifications
are.
For
example,
you
know
if
we
decide
to
kill
Maps,
then
we
could
loosen
the
restriction
of
my
character,
sets
and
stuff
like
that,
and
if
we
definitely
keep
maps,
then
we
just
need
guidance
for
things
to
prevail.
Watch
out
for
so
we'll
see
what
what
Jim
comes
up
with
him.
H
A
H
A
I
think
that's
where
Jim
was
actually
suggesting
that
maybe
he's
paying
for
right
now
we
start
off
with
saying
sure
you
can
use
a
map,
but
only
one
level,
because
we
can
always
extend
it
later.
If
we've
really
had
it
Nate
honestly,
I
don't
know,
I'd
have
to
go
back
in
ping.
Heaven,
unfortunately
he's
not
on
the
call
to
find
out
whether
this
was
just
a
you
know,
experimentation
and
what
the
spec
allows
versus
reality.
E
Hi
the
system
you
know
I
can
I'm
starting
I'm
starting
to
appreciate
the
other
side
of
this
one
and
see
why
you
might
want
to
restrict
to
these
things
to
primitive
values.
You
know,
singular
value
is
not
plural.
What
I
would
really
be
against
is
trying
to
invent
namespacing,
syntax
I,
think
that
would
be
a
really
really
bad
idea.
A
A
No,
no,
no,
if
name
spacing,
was
used
through
prefixes.
It
would
be
user-defined
way
of
doing
it,
but
the
other
points
of
where
I
wanna
understand.
Your
first
point,
though,
was
he
said
your
you're
starting
to
look
at
things.
For
the
other
side,
do
you
mean
that
you're
starting
to
think
that
maybe
maps
are
a
bad
idea
or
that
you
want
to
maybe
save
only
one
level
of
maps.
E
A
Because,
like
you've
been
back
for
that,
no
one,
okay,
cool
in
that
case
the
me
Evan-
just
joined
the
call.
So
let
me
pick
on
Evan
for
a
sec.
Haven't
you
actually
there?
Yes
excellent!
So
there
was
a
couple
of
questions
that
came
up
roots,
we're
talking
about
your
PR
yeah
joined
just
in
time.
Couple
of
questions,
I
remember
what
they
all
work,
I
think
one
of
the
big
one
was.
A
J
J
So
it
had
an
impact
on
people
who
weren't
using
the
feature,
oh
and
by
the
way
I
can
find
no
evidence
of
anyone
until
now
wanting
to
use
the
feature
and
looking
at
AMQP
and
HCP
and
Google
pub/sub
and
M,
none
of
them
support
these
maps
in
a
header,
natively
and
I'm
not
sure
about
any
routing
tools
that
would
be
able
to
process
them
natively
either.
Unless
you
do
something
like
we
do
in
the
HTTP
bindings,
where
we
use
hyphens
to
separate
them,
and
it
doesn't
work
very
well.
J
B
J
J
We
flattened
the
set
of
allowed
characters
in
the
attributes
and
now
there's
no,
it's
only
letters
and
numbers
and
there's
nothing
like
a
hyphen
or
an
underscore.
If
we
took
maps
out
I
think
we
could
put
a
hyphen
or
underscore
back
in
some
of
our
names
if
we
wanted
spec
version,
for
example,
to
be
hyphenated.
B
I
think
that
was
in
the
original
discussion
that
was
had.
We
discussed
multiple
things,
including
having
a
separator,
but
for
most
the
most
interoperability.
It
was
decided
that
we
only
have
the
letters
no
separators
at
all,
because
any
transport
could
theoretically
use
that
for
something
so
including
the
hyphen
and
then
because
the
hyphen
is
free.
The
HB
headers
can
use
it.
What
the
HB
headers
could
also
use
something
else
that
they
wanted
to.
B
J
B
Yeah
but
I
think
the
point
was
to
be
sort
of
forward
compatible
with
anything.
The
idea
was
also
with
potential
programming
languages
in
which
you
have
the
SDK.
The
idea
was,
if
we
have
nothing
in
terms
of
separator,
we
have
also
no
problem.
We
came
up
that
to
any
programming
language
SDK.
We
can
map
it
to
any
transport
body.
That
was
the
original
idea
to
not
provide
something
like
the
hyphen
in
there
and
then
he
became
available
in
the
four
th
EP
header.
I
A
G
Yeah
I'm
giving
a
bit
of
work
here,
I'm
trying
to
summarize
this
to
make
sure
I
fully
understand
it.
So
we
have,
we
have
to
choose
between
two
things.
One
of
the
thing
is
forcing
the
user
to
do
namespacing
themselves,
how
they
do
it
doesn't
matter
we're
forcing
the
user
to
do
that
themselves
because
it
might
be
hard
or
impossible
for
the
SDKs
and
transport
to
do
it
now.
Is
it
hard
or
is
it
impossible
to
do
it
in
the
SDKs?
G
Because
if
it's
just
come
on
I,
don't
wanna
say
like
do
we
want
to
make
the
user
experience
worse
instead
of
the
encoding
code
like
if
it's
impossible
or
very,
very
hard
to
view
in
encoding
and
transport?
Okay
offloading
to
the
years
are
very
good
namespacing,
but
if
it's
just
annoying
to
do
it
amazed
in
the
transport
them
as
the
case,
do
you
wanna
make
the
and
user
experience
worse?
Did
I
understand
this
correctly
yeah.
J
Yes,
so
my
comment
was
actually
that
having
to
deal
with
the
map
case,
as
a
user
made
the
SDK
worse,
because
you
suddenly
had
wildly
variable
types
that
were
coming
out
of
the
SDK
when
you
got
an
attribute,
and
so
you
had
to
treat
them,
you
know.
Sometimes
they
were
structured
objects
and
sometimes
they
were
simple
strings
and
sometimes
they
were
URLs
or
something
like
that
which
we
mostly
treat
his
simple
strings
anyway.
J
A
Just
poking
out
a
little
just
to
make
sure
I
understand
it.
Today
you
may
get
the
property
that
say:
integer
versus
a
string.
The
SDKs
in
general
have
to
Ford
returning
in
essence,
non
strings
right
so
and
generally
have
to
deal
with
support
more
than
one
data
type
being
returned
for
a
for
an
extension
right.
J
So,
like
spec
version
as
an
example,
if,
if
that
were
an
extension
rather
there
in
the
end
in
the
core,
looking
at
what's
on
the
screen
right
now,
here
it
says
0.5.
Is
that
a
floating
point
number?
Is
it
a
string
like
right
now
in
that
particular
case
it's
quoted,
but
if
it
were
an
HTTP
header
here,
I'm
quoted
and
we
don't
know
right.
J
Is
a
string
but
with
the
curly
brace
stuff
that
suddenly
like
not
for
the
curly
brace
stuff,
but
from
HTTP
you
can
tell
that
it's
a
map,
and
so
it's
there's
not
a
fallback
to
it's
a
string
or
a
map.
If
you
don't
know
what
it
is
in
the
SDK
and
string
or
a
map
is
a
kind
of
funny
variant
type
to
have
in
your
program.
Oh
that's.
A
G
G
A
But
I
was
actually
wondering
about
something
different
and
then
would
what
would
happen
if
we
said
unknown
extensions,
regardless
of
the
type
including
map
our
strings.
J
J
A
I
A
Agree
and
I
think
that's
nice
recently,
yeah
I
think
it's
one
of
the
reasons
people
wanted
to
drop
this,
but
that,
but
then
I'm
kind
of
wondering
it.
So
it
seems
to
me,
and
all
in
a
lot
of
those
discussions
is,
is
the
difference
between
the
spec
being
very
flexible
versus
trying
to
stop
people
from
doing
things
that
are
really
hard
or
really
stupid,
and
if
they
want
to
do
filtering
based
upon
a
map,
it's
in
their
life
is
gonna,
be
hell,
no
matter
what
they
do,
it's
it,
especially
when
things
get
sterilized
HTTP
headers.
A
So
it
seems
like
to
me
that
they
did
very
quickly
stop
doing
that
and
they
would
they
would
not
use
maps
in
that
point
they
may
from
top
global
properties,
no
matter
what
and
I'm
kind
of
wondering
whether
this
is
more
question
of
maybe
change.
What
we're
doing
a
little
bit
here
like
stop
trading
Maps
differently
for
extensions,
maybe
say
their
strings,
but
maybe
most
of
this
is
really
just
around
providing
guidance
that
says:
look
you
can
do
lots
of
stupid
things
with
respect
is
flexible,
but
you
really
shouldn't
do
this
this
this.
J
I'm
in
favor
of
making
it
a
map
of
string
to
simple
pipe,
which
is
basically
what
the
P
R
does
and
then
you
know,
have
people
use
prefixes
and
maybe
introduce
a
non
alpha
character.
That
would
be
met
that
you
know,
every
transport
has
to
say
how
you
map
underscore
to
the
right
thing
in
that
transport.
A
I
think
the
poem
we're
running
into
is
people's
people
seem
to
be
going
back
and
forth.
There
are
times
I
think
yes,
fine
screw
it
maps
are
too
hard.
This
get
rid
of
all.
But
then,
when
you
start
looking
at
things
from
an
end
user
perspective,
most
are
thinking
about
really
I'm
gonna
have
to
figure
out
my
own
little
prefix
scheme.
If
I
want
to
do
this
context
and
correlation
thing,
I
can't
do
a
very
simple
little
grouping
mechanism
like
this
BBS
thing,
I
mean.
A
J
A
I'm
not
saying
with
collisions,
I
think
the
guy
I'm
trying
to
echo
what
I'm
here
for
the
people
is.
Is
this.
This
grouping
mechanism
is
very
natural
for
people
to
wrap
their
heads
around
to
say:
oh,
you
wanna
go
via
mechanism
prefix
for
things
with
with
some
BBS
underscore
thing.
Technically
it
can
work.
What
I'm
hearing
from
people
is?
It's
a
user.
It's
a
non!
Very
it's
a,
not
a
very
user
friendly
way
of
doing.
It
is
what
I'm
hearing
and
I
think
that's
the
concern.
A
What
people
have
is
we're
taking
something
that
everybody
seems
to
get
wrap
their
heads
around
very
nicely,
which
is
hey
and
Jason.
You
can
do
this
simple
little
at
least
one
level
grouping
thing
and
that
that's
really
convenient
for
me,
but
in
crowd
event,
certainly
you
lose
that
ability
and
I
think
we're
hearing
some
people
getting
a
little
nervous
about
that.
I
Sure
I
just
wanted
to
add
at
one
point
you
were
talking
about
DJs
and
encoded
objects.
That's
actually
what
we
do
now.
The
string
encoding
for
objects
is
the
JSON
object,
so
it's
for
all
transferred
bindings
that
don't
specifically
state
that
they
do
the
hyphens
or
something
like
the
HTTP
one
arm.
So,
for
example,
for
the
nqb
nqp
transferred
finding
the
correct
way
would
be
to
JSON
encode
it
now
and.
G
So
somebody
mentioned
fitting
unknown
expansions
as
a
string
which
might
be
a
map,
and
then
somebody
else
pointed
out
that
that
would
make
routing
on
that
and
filtering
on
that
very
very
hard,
because
that's
very
hard
to
do
in
JSON
and
very
computation
intensive,
and
that
was
a
very,
very
good
point
and
as
a
user
I
would
much
rather
be
able
to
filter
on
the
stuff
I'm.
Putting
in
a
map
then
not
before
being
forced
to
do
your
prefixes.
G
So
whatever
we
choose
I,
we
need
to
be
able
to
have
easy
life
for
transports,
and
intermediary
is
a
middleware
to
be
able
to
do
filtering
on
whatever
level
depths
of
a
map.
That's
something
about
over
whatever
level
depth
is
extension,
because
if
I
put
something
on
as
an
extension,
I
definitely
want
that
to
be
able
to
fill
to
be
filled
or
not
right.
A
A
Would
it
be
possible
for
you
to
to
write
up
sort
of
the
pros
and
cons
and
a
very,
very
concise
list,
not
not
railing
paragraphs,
just
very,
very
short,
little
list
of
here's,
the
the
good
things
and
bad
things
about
with
everything
today
and
here's
the
good
and
bad
things
about
things.
The
way
life
will
be
after
your
PR
I
will.
A
Yeah
bids
on
biases,
if
you
can't
buy
understand
it,
is
your
baby,
that's
fine,
understood
but
I
think
I
think
we
need
something.
That's
simple
for
people
to
sort
of
look
at
it
and
compare
it
without
getting
lost
in
pages
and
pages
of
text.
So,
okay,
miss
Mayer,
they'll,
help
people
make
a
decision
one
way
or
the
other
okay,
and
just
so
you
know
before
you
joined
Jim
was
gonna
write
up
some
text
about
guidance.
If
we
kept
things
the
way
they
are
today
and.
J
J
J
A
A
Mohan
you
there
what
about
run
yep,
I'm
here,
okay,
Mohan,
Savio,
think
Oh,
Thank,
You,
Fabio,
I'm,
sorry,
I,
miss
you,
okay,
no
one!
Unless
chance,
okay's
anybody
else,
I
missed
all
right
cool.
Can
you
guys
imagine
just
reminder
if
you
were
gonna
join
the
SDK
call
we're
not
having
it
today
got
cancelled,
I
ain't
as
many
comments
or
questions
for
anybody.