►
From YouTube: CNCF Serverless WG 2020-01-30
Description
CNCF Serverless WG 2020-01-30
A
A
B
B
B
Yeah
guy,
my
wife
works
with
Karen
where
he
went.
It
was
your
China
or
South
America,
but
he
came
back
with
something
really
nasty
and
she
ended
up
giving
it
to
me
and
I've
I've
never
been
wiped
out
quite
as
bad
as
that,
and
it
just
you
know,
sort
of
reminds
you
of
sort
of
the
danger
of
hanging
around
with
people
who
travel
a
lot.
You
don't
know
what
you're
gonna
pick.
B
B
D
B
D
B
E
D
B
F
J
H
B
All
right,
three:
after
when
I
gonna
get
started,
nobody
is
worth
talking
about
community
time
anything
from
the
community
if
you
want
to
bring
up
okay,
in
that
case,
let's
go
on
to
EU
planning
or
coop
kind
of
you.
So
a
couple
things
here,
first
make
sure
if
you
are
going
I'd
love
to
get
your
name
in
there.
Just
we
can
get
it
count
for
the
face-to-face
meeting.
I!
Guess
if
you're
not
going
to
go
the
face-to-face
meeting,
we
don't
technically
need
to
know,
but
it
would
still
be
nice.
B
Maybe
I
can
group
some
people
in
for
the
kiosk,
we're
gonna
be
doing
for
the
service
session.
I
believe
they're
still
working
on
the
exact
list
of
speakers
and
with
the
abstracts
gonna
look
like,
but
we
did
at
least
get
something
submitted
so
they're
on
a
schedule
just
work
out
the
details
there
for
the
cloud
event
session,
Clemens
volunteered
to
cover
the
the
new
spec
itself
and
I'll
just
do
a
quick
overview
of
the
see
stuff
in
terms
of
the
deep
dive,
since
no
one
else
volunteered
here,
I'm
gonna
assume
that
Scott
you're.
B
Okay
with
being
that
the
lone
single
speaker
since,
like
me,
relatively
quick,
but
you
have
lots
of
volunteers
here
for
helping
the
lab-
that's
not!
Okay
to
you
sounds
great.
Okay,
cool
and
I
did
get
an
answer
on
the
kiosk
or
one
other
two
answers
so
viel.
They
wanted
to
know
whether
we
were
limited
to
just
am/pm
for
the
same
for
all
days
or
whether
we
can
alternate
during
days.
They
said
we
can't
alternate
if
he
wanted
to,
even
though
in
the
past
it
was
typically
either
just
morning
or
just
afternoon.
B
One
thing:
I
did
not
get
a
clearance
round.
Yet
is
what
does
this
last
option
mean
whether
it's
just
random,
whatever
we
want
to
show
up,
and
how
does
that
work?
Luckily,
we
don't
have
to
actually
answer
to
the
14th
so
a
little
bit
of
time
to
figure
that
out,
but
I'd
least
want
to
give
you
guys
that
answer
there.
B
B
Somebody
else,
I
believe
they're
in
Europe
did
ping
me
saying
that
they
had
some
intern
to
put
together
this
little
SDK,
but
he's
not
quite
sure
whether
those
folks
who
actually
want
to
continue
working
on
it
because
they
were
just
interns,
went
back
to
school
and
stuff,
so
I'm
trying
to
get
a
little
more
information
from
them
in
terms
of
whether
they
want
to
promote
that
as
a
possible
rest
SDK.
Maybe
you
merge
with
these
guys
up
here,
so
I,
don't
want
to
say,
ask
for
a
formal
vote
or
anything
get
it
done.
B
This
call
about
this
one,
because
I
won't
find
out
about
the
possibility
of
merging
the
efforts,
but
I
do
want
to
draw
your
attention
to
it.
So
if
you
guys
could
take
a
look
at
it
see
if
it
seems
like
it
worthy
start,
it
seemed
like
an
okay
thing
to
me,
relatively
on
the
smallish
side
like
I'm,
not
sure
it
Nestle
had
always
different
protocols,
but
as
long
as
they're
willing
to
work
on
that
and
add
more
I
didn't
see
an
issue
with
it.
B
B
So
I
would
recommend
that
unless
anybody
knows
somebody
who
wants
to
die,
she
managed
that
I
would
suggest
that
we
actually
archive
that
I
wasn't
going
to
propose
that
we
delete
the
repository,
but
rather
just
change
the
name
or
something
to
indicate
that
it's
not
being
worked
on
its
archived
and
he
may
be
deleted
in
the
future.
But
I
don't
want
to
lose
the
code
that
may
have
been
done
so
far.
D
J
B
G
A
G
B
J
Sure
the
talk
on
Friday,
the
the
biggest
changes
that
came
in
is
a
little
bit
more
Annunciation
in
some
use
cases.
In
particular,
we
were
discussing
this
the
second
paragraph
there
about
how
you
might
aggregate
discovery
or
be
sort
of
middleware
for
discovery.
So
the
trying
to
think
about
the
the
difference
there
I
might
provide
like
a
useful
collection.
G
That's
pretty
much
it
I
think.
What
we
are
we
were
discussing
is
Howie.
Is
it
the
producer
that
will
so
if
we
say
it
wears
a
boundary
for
that
API,
this
camera
API,
so
I
think
we
decided
to
the
producer
boundaries
producer
will
provide
that
then
there's
a
question
is
if
there's
a
middleware
either
it's
a
gateway
or
whatever
right.
Is
that
producer
all
that
just
a
transparent
entity
which
will
pass
the
order
discovery
api's
to
the
producer,
or
we
define
that
as
a
producer.
C
Amended
the
the
documents
with
some
explanation
of
what
the
kinds
of
subscriptions
are,
that
we
ought
to
cover
and
there's
effectively
two
models,
and
we
spoke
about
this
on
our
call
effectively
two
models:
there's
a
full
subscription
where
you
walk
up
to
some
typically
some
middleware,
but
that
necessarily
middleware
and
you
use
a
gesture.
Typically,
the
application
protocol
to
start
soliciting
events
from
there,
which
is
pull
and
the
other
model
is
where
you
effectively
configure
some
sort
of
pops
up
engine
or
the
producer
itself
to
deliver.
C
Events
to
a
target
which
might
be
directed
at
the
subscriber
itself
or
might
be
directly
might
be
directed
elsewhere,
where
the
subscriber
effectively
acts
on
on
behalf
of
that
target.
And
so
that's
the
push
model.
And
ultimately
it's
a
you
know
whether
the
and
so
the
pull
model
sorry
is
typically
done
using
some
level
of
pub/sub
protocol
and
so
I've
covered.
C
The
cases
here
explicitly
explain
the
methods
that
exist
in
n
QT
m
capilla
Nats,
which
is
which
are
the
the
true
Pops
of
protocols
that
we
that
we
support,
which
allow
you
for
some
level
of
filtering
on
advanced
stream
or
on
events,
and
there
is
no
while,
while
this
is
practiced
also
with
HTTP,
you
know
to
be
able
to
walk
up
to
a
event
store
of
some
sort
and
pull
events
out.
There
is
no
I
would
argue
standardized
mechanism
to
do
this,
so
I've.
What
I've
done
here?
C
What
the
goal
was
of
this
section
is
to
basically
prescribe
describe
what
exists
in
the
existing
protocols,
with
the
goal
that,
if
you
are
using
an
MQTT
broker
and
using
amputee
amputee
broker
with
cloud
events,
then
you
should
not
need
extra
magic
to
manage
subscriptions
right.
It
should
be
within
the
scope
of
the
specification.
C
You
know
checklist
compliance
verifications
where
you
know,
there's
no
asking
you
are
you
supporting
cloud
events
subscriptions
and
you
know
you
should
be
able
to
say
to
say:
yes,
if
you
do
it
with
the
MQTT
protocol
or
with
the
mqp
protocol,
with
an
ATS
protocol
without
having
to
do
any
unnatural
acts.
So
that's
why
I
have
this
in
here
and
then
we've
moved
on
to
you
know
talking
about
some
some
of
the
for
subscriptions,
which
is
effective.
C
Then
then
configuring,
the
the
middleware
or
the
the
producer-
and
there
is
an
interaction
that
obviously
needs
to
exist
with
discovery
mechanism,
because
we
think
of
the
the
at
least
that's
what
we
were.
We
were
headed
I.
Think
the
other
thing
correct
me
as
the
subscription
API
and
the
discovery.
Api
is
really
clearly
distinct
and
the
discovery
API
should
yield
the
endpoint.
Where
you
can
go
and
subscribe
and
should
then
also
yield
what
the
protocol
is
by
which
you
can
can
subscribe,
and
then
you
in
fact
establish
a
subscription
over
the
endpoint.
C
C
One
of
the
things
that
we've
we
talked
about
is
that
we
need
to
go
and
specialize
that
for
various
transports
and
a
minimum
for
all
the
transports
that
we
have
as
part
of
caught
in
the
core
of
cloud
events,
and
it
also
makes
it
extensible,
because
we
have
at
least
from
a
security
perspective,
and
let's
start
there,
we
have
two
contexts.
We
have
the
context
of
being
able
to
subscribe.
C
You
know.
Different
security
context
that
we
have
here
are
interacting
and
then
also
how
stuff
works
like
renewal,
because,
if
you're
setting
up
a
subscription
and
that
subscription
is
long-lived
over
months
or
years,
it's
hard
for
me
to
imagine
that
for
interoperable
solution
we
get
around
doing
something
like
OAuth,
where
you
get
a
renewal
token,
and
then
you
have
to
present
that
renewal
token,
occasionally
to
a
an
STS
which
in
Access
circuit
breaker.
So
we
that's.
C
The
oauth2
is
the
model
that
I
think
has
the
broadest
consensus
around
the
industry,
and
it's
hard
for
me
to
imagine
that
we
can
get
around
using
a
mechanism
like
this
across
protocol
boundaries
here
and
so
we're
going
to
look
at
the
information
at
that
information
model
for
specifically
around
push
for
the
various
transports.
You
know
what
the
information
is,
that
we
need,
and
also
what
is
the
transferred
information,
the
transport
information
that
we
need,
for
instance,
for
mqtt.
F
Yes,
a
quick
one,
I
didn't
sorry,
but
in
case
of
broker
based
subsystem
is
that
would
that
be
transparent?
So
would
consist
of
two
subscriptions
one
being
the
broker
asking
the
the
origin
of
the
event
to
submit
events
to
the
broker
and
a
second
subscription
of
consumer
to
ask
the
broker
to
deliver
event.
So
we.
C
Have
we
have
this
this
transitive
scenario
with
tables
for
the
initial
rounds?
We
talked
about
this
initially
I
think
we'll
have
to
get
to
it,
but
it
adds
quite
a
bit
of
complication,
I
think
the
way
we
get
around
this
is
by
so
let
me
back
out.
There
is
a
clear
need
in
some
scenarios
where
you
have
such
scale
at
the
producer
side,
that
you
want
to
avoid
raising
events
that
you
know
are
not
being
consumed,
and
then
there
is
such
scale
at
the
consumer
side
that
the
producer
can't
possibly
handle
that
load.
C
So
in
those
scenarios
of
which
we
have
in
Asscher
a
few,
for
instance,
in
in
case
of
Azure
storage,
raising
events,
we
literally
go
and
notify
Azure
storage
from
event
grid,
whether
there
are
any
of
any
subscriptions
and
only
then
they
turn
on
the
event
feed
for
that
particular
context,
and
when
there,
when
all
the
subscriptions
are
gone,
we
tell
them
to
go
and
turn
off
that
events
event
feed.
So
that's
a
that
is,
is
something
that
I
know
is
required.
C
I
would
I
would
like
to
focus
on
getting
the
simple
case
managed
first
and
then
see
what
the
upstream
model
needs
to
be
to
effectively
communicate
that
that
subscription
up
to
the
source,
because
the
mechanism
is
not
necessarily
trivial,
because
the
producers
relationship
to
a
middleware
is
usually
one
where
they
simply
send,
and
you
don't
necessarily
have
a
back
path
to
them
for
how
you
can
tell
them
how
to
you,
don't
necessarily
have
a
subscription
API
on
that
producer.
Exactly.
C
It
starts
ref,
counting
on
those
on
those
events
and
will
then
you
know
if
there
is
a
is
an
endpoint
that
it
can
call
to
go
and
trigger
subscriptions
for
events
on
that
producer.
It
will
do
so,
and
otherwise,
if
there's
no
sort
of
subscription
URI
that
basically
indicates
that
the
producer
will
produce
at
all
times
and
it
will
basically
just
deliver
through
the
middleware.
C
So
there's
a
mechanism:
we
can
go
and
figure
out
to
communicate
that
fact
and
either
make
it
active,
because
you
need
to
have
a
back
path
or
to
make
it
passes
where
the
producer
always
produces
into
the
middleware
and
then
basically
delegate
subscription
to
it.
So
I
think
we
won't
find
a
relatively
elegant
way
for
that.
K
Just
wondering
it
sounds
like
would
all
work
if
you
assumed
everything
was
a
fully
qualified.
You
know
subscription
to
like
a
delimited
topic.
However,
most
producers
have
it
like
a
canonical
representation.
Reach
field
is
significant,
but
every
time
you
publish
those
fields
will
vary.
You
know
a
case
in
point
might
be
a
simple
stock
market
publisher
from
a
gateway
yeah,
where
there
is
like
10,000
trading
instruments,
and
that
would
be
one
field.
So
if
you
went
to
subscribe,
how
would
it
know
the
ten
thousand
subscriptions?
How
do
you
apply
wild
cards?
C
We
talked
we
briefly
touched
on
this,
but
not
to,
and
on
the
previous
call,
we
had
in
terms
of
letters
and
you'll
see
that
there's
a
filters
field
filtering
is
something
we'll
have
to
go
and
support.
It's
just
not
yet
clear
to
me
to
what
level
we
can
achieve
agreements
unfiltered
and
we'll
certainly
try
on
the
filters
model.
Just
just
for
once
again.
C
So
yeah
there's
some
precedent
and
there's
also
in
terms
of
filters
depending
on
what
the
product
isn't.
The
protocol
is
that
you
that
you're
working
with-
and
they
are
already
built
in
and
they're
already
kind
of
implied
by
what
what
people
practice
so
I.
Yes,
so
I
believe
that
there
must
be
a
filtering
mechanism
that
there
must
be
a
way
to
have
differentiation
by
subject,
differentiation,
probably
or
even
by
custom,
but
what
the
filter
language
is.
C
H
Hands
next,
yes,
so
I
think
yeah.
The
filters
are
important,
therefore
feels
like
subject
and
so
on,
but
there
are
also
feels
that
typically
more
go
into
the
topics
like
the
source
and
even
the
base
we
have
defined
sauce.
It
might
also
vary
so
I'm,
not
sure
if
in
all
cases
that
it
will
be
possible
to
have
a
fixed
list
sources
of
a
producer.
There
are
some
fields
like
I,
don't
know
if
the
sauce
is
something
like
a
workflow
or
ID,
or
something
that
might
vary
a
lot
so
I
wonder
if
really
also
discovery.
C
I
think
you
will
have
to
four
subjects.
You
will
certainly
have
to
four
sources
you
might,
depending
on
what
the
scale
of
those
are
of
the
systems.
Are
you
may
make
sense,
I'm,
not
sure
whether
it
makes
whether
it's
useful
to
have
a
hundred
thousand
different
event
individual
event,
catalog
registrations
for
what
is
effectively
the
same
event,
but
by
different
instances
of
a
system
yeah.
H
K
It's
just
on
the
my
original
question.
Actually,
my
biggest
concern
was
more
on
the
subscription
discovery.
Where
again,
if
I
have
you
know
to
use
the
stock
market
type
scenario,
if
I
have
one
field
that
has
10,000
different
potential
enumerations
in
that
field,
I
mean
have
you
got
suggestions,
and
how
would
you
do
that
discovery
which
then
would
lead
to
I
would
need
to
know
how
some
way
to
either
potentially
filter?
But,
more
importantly,
if
I
have
it
as
a
fully
qualified
man,
how
do
I
know
that
fully
qualified
name?
C
J
I
First
of
all,
I'll
echo
the
idea
that
a
source,
at
least
a
Trulia,
we
think
of
a
source
as
an
instance
of
some
kind
of
object
or
something
that
emits
events,
and
that
is
definitely
not
static.
So,
for
example,
at
Coolio
you
might
have
an
instance
of
a
phone
call
that
has
a
specific
identifier
that
is
short-lived
just
for
the
lifetime
of
that
call,
and
you
might
have
consumers
that
want
to
subscribe
events
for
particular
calls
or
particular
messages,
etc.
So,
oh
echo
just
that
that
thought.
I
The
the
second
comment
I
wanted
to
make
is
another
thing
we
talked
about
on.
The
call
was
you
know
what
goes
into
we
have
this?
Can
fake
map
so
I
would
prefer
to
be
opinionated
about
what
goes
into
there
and
I
think
the
sort
of
verbal
agreement
that
we
had
was
that
should
be
essentially
just
transports
specific
configuration,
whereas
other
other
configuration
or
other
other
things
that
you
need
to
put
into
the
subscription
should
probably
be
promoted
to
the
top
level.
So,
for
example,
I
did
comment
on
the
filters.
I
know
you.
L
L
C
What
we've
done
on
event
grid,
for
instance,
is
instead
of
having
a
complex
filtering
filtering
model.
We
have
initially
affected
the
three
filter
conditions.
That's
our
simple
filter
model
effectively,
which
is
a
prefix
and
suffix.
So
that's
a
there's,
a
full
match
and
prefix
and
suffix
condition
on
type
subject
and
source.
C
So
that's
the
the
minimal
the
the
minimal
set
that
we
have,
so
you
can
effectively
if
you're
looking
for
you
know
a
blob
created
events
from
a
storm
storage
and
you
only
want
to
have
the
events
for
JPEG
files.
All
right,
you
make
a
you
make
a
filter
for
the
type
blob
created
the
source
is
then
effective,
matching
the
container.
C
What
you
want
to
have
that
from
and
then
the
subject
is
a
suffix
filter
on
JP,
JP
J
and
that's
and
that's
kind
of,
and
that's
the
the
the
simple
condition,
and
then
we
added
also
a
direct
match
table
for
attributes
that
can
set
on
that
on
the
on
the
event
which
is
affected.
Just
the
you
know,
key
value
pairs
with
the
expected
values
and
if
they
match
match
directly,
then
that's
also
metric.
So
we
can
start
with
something:
that's
that's
that
simple
and
then
see
wow.
That's
when
that's
efficient,
yeah.
L
Cuz
I'm,
it
just
seems,
like
you
can
say
we
can
do.
We
can't
agree
on
anything
and
I
think
that
there's
some
things
that
we
kind
of
all
agree
on
that
would
add
some
value.
The
users
today
that
we
could
probably
start
and
those
seem
like
reasonable
things
to
look
at
so
just
limit
the
further
out
there
I'll.
B
Okay,
I'll
go
in
hinds,
we'll
jump
over
you
and
I'm,
not
actually
looking
for
you
guys
to
do
more
work,
but
it
does
dawn
on
me
that
in
this
in
the
cloud
of
inspect
my
work
on
that
we
did
end
up
producing
a
document
that
talked
about.
You
know
what
are
the
current
events
that
are
produced
by
the
various
products
out
there
today,
just
as
a
informational
kind
of
a
thing,
I'm
wondering,
as
you
guys
are
producing
or
doing
your
analysis
to
figure
out
what
we
want
to
put
in
this
spec.
B
What's
out
there
today,
I
think
that
might
be
interesting
if
you
guys,
for
both
sections
of
the
spec,
could
could
do
that
because
I'm
not
that
saying
looking
for
extra
work.
But
if
you
happen
to
be
doing
it
anyway,
you
might
have
to
just
toss
it
in
the
docs.
We
have
it
as
reference
and
with
that
I'll
hand
it
over
to
Heinz.
K
However,
most
if
you're
targeting
the
messaging
systems,
all
the
filtering
is
based
only
on
the
topic
or
cue
name,
so
I'm
just
wondering
how
are
you
going
to
blend
those
two
together
and
if
the
intention
is
like
a
pre-filter,
where
once
I
receive
the
message,
maybe
based
on
the
top
or
the
event
based
on
a
topic
that
I
would
decide
if
I
want
to
see
it
or
not,
those
are
usually
frowned
upon
is
if
you
are
going
to
an
async
push
model.
The
last
thing
I
want
to
do
is
not
have
the
broker.
A
C
So
I
would
I
disagree
with
that
because
the
so
there
are
some
brokers
which
are
relatively
simple,
so
Nats
as
a
subject
based
model
mqt
has
a
literally
has
this
topic.
The
topic
model,
which
is
based
on
the
the
original
mq
topic
model,
but
every
most
most
modern,
most
modern
enterprise
brokers
actually
have
a
fairly
sophisticated
way
of
doing
filters.
So
if
you
look
at
ActiveMQ,
if
you
look
at
you
know,
MQ
them
the
modern
version
of
topics
in
in
MQ.
C
K
Not
correct,
it
only
does
inspection
on
headers.
They
only
use
selector
functions,
which
are
also
kill
performance
and
are
usually
for
all
those
protocols
not
recommended
because
they
were
originally
designed
for
addressing
that
didn't
support
a
hierarchical
address.
So
that
was
the
way
they
could
do
some
more
so.
C
I,
don't
think
that's
true,
because
we
certainly,
we
certainly
recommend
that
you
use
them
and
our
customers
are
using
them
a
lot
across
thousands
of
customers
and
what
we
see,
customers
that
are
coming
with
lift
and
shift
workloads
from
other
brokers
into
the
azure
cloud,
mostly
everybody
using
message,
selectors
for
all
kinds
of
scenarios.
So
so
they
are
very
very
common.
And
yes,
they
only
operate
on
the
metadata
of
the
message.
But
that
is
exactly
in
tune
with
with
the
the
spirit
of
what
we
did
in
cloud
events.
C
Years
actually
so,
I
know
that
it
affects
performance
right,
but
it's
also
a
fact
that
they
are
there
they're
intensively
used
in
all
those
broker.
Products
I
mean
I
run
one
so
so
I
mean
we
can.
We
can
tell
what
that
costs,
and
we
and
customers
know
what
that
costs,
but
we
have
enough
firepower
for
four
customers
to
use
them
and
they
do
so.
B
J
I
just
wanted
to
point
out
that
we
need
to
align
the
filter
piece
between
both
the
subscriptions
and
the
discovery,
so
I
put
some
filter
specific
stuff
in
discovery,
which
is
different.
What's
up
here
in
particular,
echoing
would
be
like
I,
said,
I
think
it's
interesting
to
think
about
providing
some
cloud.
Events
attribute
specific
filtering,
as
these
are
meant
to
transit
cloud
events,
but
also
acknowledging
that
certain
producers
are
gonna
have
different
domain-specific
languages
that
that
need
to
be
there
in
order
to
like
power.
J
B
B
B
I,
can't
you
see
her.
The
Avro
spec
and
the
Kafka
spec
were
missing
an
entry
for
the
under
v1
Oh
column.
So
let
me
show
you
what
it
looks
like
did
you
do
so
on
the
mainland
right
now,
that's
blank
and
that's
blank
and
I
can't
for
life
me
remember
if
I
just
messed
up
or
whether
we
actually
did
not
choose
to
promote
those
to
one
point,
though,
for
some
reason
does
anybody
remember.
B
D
B
We
don't
know
second
right
out
and
say
you
can't
go
past,
that
it
is
kind
of
a
strong
hint
to
keep
things
relatively
small
right,
yeah,
and
so
what
I
thought?
Okay,
that
might
be
useful
to
add
into
the
primer
so
I
had
it.
Some
texture
for
the
primer,
I'm,
not
gonna,
suggest
that
we
approve
this
here,
because
I
just
put
it
there
yesterday
and
there's
a
rule,
it
says:
everything's
be
there
for
two
days,
but
please,
when
you
get
a
chance,
take
a
look
at
this
and
obviously
in
particular
Clemens.
B
B
B
J
B
Correctly
so
because
my
hands
up,
let
me
ask
a
quick
question
Scott
in
this
second
example:
I
did
this
the
one
that
really
confused
me
when
you
say
that
this
can
be
interpreted
as
sort
of
encoded
Jason?
My
understanding
from
reading
the
spec
this
morning
anyway
was
from
the
cloud
event
perspective.
This
is
a
string.
The
fact
that
it
looks
like
Jason
is
irrelevant
to
the
spec
right,
the
application
when
it
receives
it,
it
can
do
some
inspection
and
say:
hey.
B
C
C
So
there's
effectively,
there's
a
there's,
an
implication
that,
if
that
it
is
adjacent
value
which
includes
JSON
objects
and
which
means,
in
the
jason
case,
when
it's
when
it's
defined,
where
the
data
content
type
is
declared
and
that
this
is
jason,
then
it's
expected
that
in
the
JSON
format,
which
is
the
only
case
where
that
can
happen,
that
it
is
that
the
data
content
is
effectively.
If
it's
not
database
64,
which
means
it's
not
binary,
then
it
is
always
adjacent
value,
which
means
that
case
is
a
string.
If.
C
C
C
H
C
Good,
even
foot
so
so
the
thing
is
even
for
the
cake.
So
when
it
is
not
binary
right,
so
it's
not
basic
64
encoded.
Then
it
is
always
a
Jason
value
and
then,
if
it,
if
the
data
content
types
has
text
XML
the
you
find,
then
you
know
you're
expecting
text
and
you'll
find
the
text
in
the
string,
because
it's
not
in
this
other
way.
But
if
it
says
Jason
well,
then
you
have
adjacent
value
that
can
interpret
directly
yeah
yeah.
J
B
B
What's
the
word
admins,
you
know
the
the
guys
would
manage
the
phone
calls
and
manage
all
the
Gorp
for
us.
You
know
because
everybody's
maintainer,
based
upon
voting
rights
but
relative
to
the
administrative
tasks,
I
think
there's
three
of
us.
There's
me
mark
and
Ken
and
we
probably
need
some
documentation.
The
governance
talk
that
says:
how
do
you
add
or
remove
people
from
there
and
every
now
and
then
I
think
about
this
and
I
was
gonna,
write
a
PR,
but
I
didn't
get
around
to
it.
B
But
let
me
ask
you
guys
whether
you're,
okay
with
me,
the
general
direction
of
what
I
want
to
write
up
and
my
basic
thought
process
is.
If
you
want
to
remove
one
of
the
admins,
then
all
you
requires
is
greater
than
50%
vote
from
the
voting
members.
If
you,
if
someone
wants
to
be
added
as
an
admin
again
greater
than
50%
of
the
votes
of
the
voter
members,
so
basically
that's
how
you
can
add
and
remove
administrative
folks.
C
B
Have
a
discussion
about
that?
Okay!
That's
a
good
point,
though.
I
need
that
text.
Another
says
how
does
someone
you
know
get
out
of
this
role
if
they
want
it
and
can't
obviously
force
them,
but
I
should
had
sex
that
effect.
So
thank
you
Clemens
for
the
joke,
but
do
you
put
something
in
there
for
that
bus
factor?