►
From YouTube: GMT 2018-03-06 API WG
Description
No description was provided for this meeting.
If this is YOUR meeting, an easy way to fix this is to add a description to your video, wherever mtngs.io found it (probably YouTube).
A
B
A
A
A
A
A
C
C
So
I
went
ahead
and
started
the
recording,
so
I'm
excited
to
get
the
API
working
group
started.
I
think
that
it'll
be
good
to
have
a
central
place
for
us
to
talk
about
API,
related
issues
and
new
features.
I
think
that
one
of
the
difficulties
that
an
open-source
project
has
is
that
there
are
people
from
disparate
places
and
with
disparate
motivations,
working
on
the
same
code
base
which
can
lead
to
inconsistencies
when
people
just
don't
end
up
communicating.
C
C
So
maybe
we
can
start
talking
about
the
second
item
here.
First
and
of
course,
if
anybody
has
other
things,
they
want
to
add
to
this
list
now
or
as
we
go
feel
free,
so
I
thought
it
would
make
sense
for
us
to
start
off.
Oh
and
I
should
mention
that
I
think
Vinod
is
on
leave
right
now
and
that's
why
he
wasn't
able
to
join,
but
he'll
definitely
be
here
once
he's
back
at
work.
C
Going
forward.
He'll
also
be
attending
these
meetings
for
sure,
because
he's
one
of
the
probably
the
point
of
contact
currently
for
big
changes,
so
I
thought
we
could
discuss
just
what
we
envisioned
or
this
working
group.
What
types
of
things
we
would
like
to
accomplish
here
so
I
think
I
mean
one
of
the
obvious
purposes
to
me
is
just
to
provide
a
forum
to
discuss
API
related
issues
and
new
features
that
people
are
adding
I.
C
Think
that's
in
line
with
what
the
other
working
groups
and
one
thing
that
had
occurred
to
me
and
I,
don't
really
know
if
I
think
this
is
a
good
idea
or
not,
but
one
thing
that
had
occurred
to
me.
One
possible
purpose
for
this
working
group
is
to
serve
as
kind
of
a
committee
for
approval
of
new
API
changes.
C
If
someone
wants
to
alter
an
existing
interface
or
introduce
some
significant
extension
of
an
API
that
this
working
group
could
be
like
an
entry
point
for
those
new
developments
and
that
could
help
us
ensure
consistency
in
the
API.
So
that's
one
thing:
I
kind
of
wanted
to
bring
up
and
just
ask
all
of
y'all.
If
you
think
that
that's
a
reasonable
idea
is
that's
something
we
should
seek
to
do
in
this
working
group,
or
is
that
not
does
that
not
make
makes
what
do
y'all
think.
C
D
I
think
that
makes
sense
I
don't
see
a
reason
not
to
do
that
like
have
discussion
on
public
API
is
always
good
and
instead
of
like
on
like
burying
some
review
request,
I'm
getting
review
board
other
rather
like
have
a
more
public
discussion
on
all
the
API
changes
that
we
plan
to
do
in
this
project.
C
B
I
think
that's
where
there's
a
little
bit
of
a
potential
hindrance.
Like
the
very
least.
You
would
hope
that
you
get
surface
API
changes
on
the
mailing
list
to
make
it
less
of
a
just
a
review
flying
by
and
no-one's.
Really.
No
one
really
knows
that's
happening
mm-hmm
and
then
you
know
if
people
are
like
hey,
this
really
doesn't
quite
seem
right.
Can
we
talk
about
this?
D
B
This
is
another
thing,
I've
kind
of
noticed
that
for
better
and
for
worse,
like
due
to
slack,
we
don't
you,
don't
nearly
have
enough
conversations
on
the
dev
list
anymore,
things
kind
of
slip
by
and
slack
and
I-
don't
know
about
others,
but
I'm,
trying
to
actually
like
reduce
the
amount.
That
slack
is
constantly
distracting
me,
which
means
I'll,
sometimes
I,
miss
those
like
important
conversations
that
are
happening
because
they're
occurring
synchronously
on
slack,
something
like
an
API
change.
C
Yeah
and
it's
something
that
we
have
a
good
record
of,
which
is
useful,
right,
I,
think
having
a
like
a
tiered
system
that
you
described
been
where
we
ask
everyone
to
surface
API,
changes
on
the
mailing
list
and
then
use
that
as
an
opportunity
for
people
to
push
push
it
into
the
working
group.
If
further
discussion
is,
is
necessary.
That
sounds
pretty
good
to
me.
E
That's
one
of
my
questions
is
like
if
we
were
gonna
push
API
changes
into
this,
where
I
can
really
twist
up
where
we
just
like
gather
the
people
who
we
think
might
be
stakeholders
for
the
change
and
make
sure
that
they
get
to
come
to
the
working
group
too,
because
I.
Imagine
that,
like
people
with
general
interest
in
API
changes,
won't
be
the
same
set
of
people
that
have
specific
interest
in
any
given
API
change.
C
C
So
I
wanted
to
bring
up
the
second
item
because
it
kind
of
it
impacts
the
first
item,
as
we
mentioned.
How
often
we
want
to
have
these
I
was
kind
of
I
was
thinking.
It
would
be
nice
to
start
off
doing
a
regular
cadence
and
then,
if
we,
if
we
determine
that,
it's
that
it's
too
often
and
we
just
want
to
go
to
an
on-demand
schedule-
we
could
do
that,
but
I
thought
it
would
be
nice
initially
to
start
with
the
regular
cadence
and
just
see
how
that
goes.
C
C
Yeah
yeah
that
sounds
good
to
me,
so
I
think
yeah.
Maybe
we
can
start
with
bi-weekly
regular
data
and
I
could
send
out
an
email
to
devilĂs,
informing
people
that
were
we're
asking
folks
to
I
mean
I
think
hopefully,
like
you
said
Ben.
Hopefully
this
is
something
people
already
do,
but
we
can
reiterate
that
we
would
like
all
public
API
changes
to
be
announced
on
the
mailing
list
first
and
that
that'll
give
people
an
opportunity
to
ask
for
a
discussion
in
the
working
group
if
they
desire.
C
C
C
C
B
I
think
that
that
number
was
based
on
a
released,
getting
cut
every
two
months
or
supporting
three
releases
mmm-hmm.
But
since
we've
slowed
that
down,
we
we've
ended
up
continuing
support
three
releases,
but
it's
not
really
mapping
to
six
months.
I,
don't
think
yeah
we'll
have
three
active
release.
Branches.
Typically,
once
the
new
release
is
cut,
will
close
the
fourth
release
branch,
then
we'll
stop
back
printing
fixes.
F
C
Yeah,
could
you
add
an
action
item
guest
on
to
you
can
assign
it
to
me
if
you
like.
G
H
You
clarify
what
one
does
the
two
months
cycle
begins
helpful,
like
I,
think
this
unclear
from
here?
Is
it
actually,
the
correctly
the
release,
time
or
I
think
what
we
were
that
you're
doing
is
I
forgot,
we're
actually
doing
but
I
think
I.
Think
in
a
two-month
like
when
the?
When
do
we
start
counting
in
two
minds
that
might
be
helpful,
I
think
previously,
I
had
some
confusions
about
the
nest.
Do
not
exactly
sure
what
we
are
doing.
C
Yeah
I,
don't
think,
we've
been
very
strict
about
when
we
started
I
mean
the
language
here
implies
that
you
know
a
new
release
will
be
well.
It
just
says
a
new
release
will
be
done
every
two
months,
so
that
implies
that
when
the
release
is
well
I
guess
that
that's
maybe
vague
too,
is
a
talking
about
the
first
RCT
or
is
it
talking
about
the
final
yeah.
H
C
We
ended
up
holding
it
back
for
some
feature
and
we
probably
could
have
won
five
and
then
one
6.
By
the
time
we
got
one
5
out
so
I
I
kind
of
liked.
The
two-month
cadence
that
seems
pretty
good
to
me
I'd
be
curious
to
hear
what
other
people
think
if
we're
going
like.
Should
we
just
go
to
feature
based
releases
if
that's
kind
of
the
pattern
we're
following
or
it's
two
month,
two
months
of
good
cadence.
H
H
Sorry
so
from
our
side,
I
think
we
we
are
kind
of
able
to
catch
up
on
this
two
to
three
month.
Breed
cycle.
I
think
it
goes
much
more
frequent
than
that.
We
will
not
release
every
version,
but
there's
and
I
think
in
the
current
way
makes
the
bisecting
the
issues
easy
enough
for
us
like.
If
something
goes
well,
the
kids
still
reader
can,
you
know
again
see
which
change
might
have
triggered
the
problem.
H
C
I
C
E
B
E
C
Yeah,
so
what
about
one
question
I
had
let's
say
we
actually
were
sticking
to
two
months
reliably
then
would
a
six
months
six
month
support
period
be
sufficient?
Do
you
guys
think
because
currently
people
like
currently
people
are
getting
you
know
nine
months,
perhaps
of
support
I.
H
Think
we
should
still
do
three
versions
rather
than
six
months.
My
brother
say
run
answer.
Rather,
you
need
to
be.
The
man
would
I
think
three
versions
still
good,
because
from
our
experience
we
feel
like
the
first
point
of
release.
Quality
is
always
better
than
the
total
zero
one
which
is
understandable
and
I,
think
occasionally
have
seen.
H
Hatches
got,
went
to
the
second
point:
release
not
too
so
I
think
having
having
three
versions
that
will
really
increase
people's
confidence
say
if
people
strongly
prefer
stability
and
the
most
money,
if
they
don't
have
people
that
kill
myself.
Okay,
look
into
the
taking
you
deeper,
they
probably
go
with
a
pretty
conservative
way
say
looking
at
three
version,
which
is
small,
reliable,
can't
be
more
reliable,
I'd
update.
H
C
H
E
C
E
E
What
DCOs
does
is,
we
are
trying
were
like
shooting
for
timed
releases
and
then,
after
the
window,
where
we
have
supported
releases,
we'll
have
like
upon
request,
point
releases.
So
it's
like.
Oh,
we
support
three
versions
like
well
we'll
update,
we'll
back
port
and
we'll
do
all
this
stuff
for,
however,
many
versions
back,
but
then
after
that
number
of
versions.
If
someone
asks
us
for
it
will
do,
we
can
update
or
back
port
bug
fixes
to
that
version,
and
so
it's.
B
G
D
Well,
I
think,
right
now
the
problem
is
lights
and
it's
mostly
feature
based
released
not
like
time
based
like
people
have
interesting
doing
this
release
and
and
then
people
will
just
wait
for
that.
So
it's
really
hard
to
predict
that
like.
If
we
want
to
strictly
like
to
time-based
releases,
then
it
should
be
a
pretty
smooth
process
like
if
you
cannot
make
the
time
you
cannot
make
the
deadline.
It
would
not
be
part
of
that
release,
but
I
mean
in
reality
it's
pretty
hard.
C
Yeah
I
mean:
do
you
think
we
can
I
think
we
could
probably
make
a
one
six
release
happen
in
a
month
if,
because,
if
another
release
we're
actually
going
to
go
out
two
months
from
them,
I'm
guessing
at
least
people
who
I've
been
working
with,
would
probably
be
able
to
wait
until
that
one
seven
release
to
get
features
in.
Do
you
think
that's
feasible.
I
E
F
C
C
Alright,
so
the
next
thing
on
the
list
is
query:
support
for
the
api's,
for
example,
graph
QL.
This
is
something
that
it's
an
idea.
That's
been
tossed
around
a
lot
in
the
past
few
months
and
I.
Think
one
of
the
so
I
just
like
to
open
the
floor
to
generally
discuss
that
topic.
Things
in
particular
that
I
wanted
to
get
out
of
question
what
we're
some
concrete
cases
that
people
have
in
mind
for
this,
so
that
whenever
we
end
up
doing
along
those
lines
actually
makes
sense
for
people.
C
C
H
C
H
I
would
could
use
it.
I
know
it
some
time
regard
so
that
anything
unity
is
a
hard
match.
Extremism.
For
example.
We
say
we
only
authorized
a
user,
a
bootable
of
three
model
to
launch
a
task
under
a
user
I
think
that
is
the
especially
we
eventually
our
side.
Eventually,
we
only
want
to
authorize
the
framework
to
log
on.
H
The
the
matching
will
not
be
done
our
user
hard,
but
like
other
field
about
it
in
that
field
may
be
quite
quite
flexible.
I
may
not
be
able
to
introduce
one
authorization
item
for
different
entity
or
subject.
That's
a
lot.
I
mean
two
things:
whether
graft
you,
how
can
be
expressive
in
optics
to
say
that
all
you
got
under
something
else.
C
Okay,
so
I
think
one
way
in
which
we've
addressed
that,
for
other
authorization
actions
is
to
use
well,
so
we've
attempted
in
other
cases,
to
to
provide
enough
context
in
the
authorization
API
to
authorize
based
on
a
variety
of
fields.
I
think
that
task
launch
is
one
case
where
that
hasn't
been
done,
but
we
authorize
some
actions
based
on
something
like
framework
info,
which
contains
a
lot
of
information
and
people
might
authorize
based
on
different
things.
There
I'm
not
I'm,
not
sure
how
our
graph
QL
might
be.
H
C
C
I
Like
for
this
query,
baby
language,
it's
more
useful,
say
like
people,
don't
need
to
go
into
the
massive
proto
and
okay.
Okay,
it
surprised
the
structures
like
we
have
member
at
first
and
they
say
they
don't
need
to
first
go
through,
though
I'm
like
go
through
the
whole
proto
definitions,
but
can
just
do
a
curly
say
I
want
to
get
it.
I
have
a
test.
Id
I
want
to
gather
result
the
looks
task,
status,
etc.
So
it's
maybe
a
little
bit
easier
for
users
who
to
guess
they
status
or
something
Thanks,
even
without
knowing.
C
J
C
J
J
We
can
simply
find
all
all
these
fields
and
explore
because
sometimes
it's
very
hard
to
find
necessary
information
on
meses
documentation
and
that's
that
could
be
like
a
self
documented.
You
know
infrastructure
where
you
can
just
open
some
simple
page
and
execute,
always
quite
as
fine
what
what
exactly
get
from
from
masses.
B
B
You're
gonna
get
a
full
dump
of
the
state
followed
by
updates
and
that
initial
payload
might
be
still
too
big
for
people
so
I'm,
just
hoping
that
there's
something
we
can
do
where
it's
a
more
Universal
filtering
across
the
API.
Rather
than
a
specific.
You
know
graph
qlm
plane
or
something
like
that.
Yeah!
That's
a
good
point.
C
C
I
C
C
C
I
About
whether
we
like,
for
example,
we
probably
want
to
introduce
new
v2
API
you
based
on
based
on
none
like
a
PC
or
other,
obviously
a
frameworks.
So
so
we
guys
wanna
buy
with
dependent.
Our
v1
is
purely
been
reading,
anybody's
actually
hard
to
like,
remember
again
or
write
other
application
against
work,
and
so
maybe
depends
on.
Like
some
third
party
RBC
frameworks,
it's
a
good
turn
for
future
yeah.
I
One
thing
we
lose
at
least:
maybe
we
can
try
to
find
out
you
can
see,
but
the
concern
is,
first
of
all,
there's
no
like
public,
evaluate
at
performance
evaluation
to
you
for
using
GBC
in
production.
That
would
be
the
main
concern
and
also
for
juggling
severe
some
difficulties
that
I
chatted
with
and
about
like.
We
have
multiple
hav
server
service.
It's
not
like
I
all
like
it
has
only
been
moved
for
trial
process
in
which
maybe
I'm
in
hell
with
our
permitting
process.
There
are
some
other
things
we
probably
others.
I
D
Yeah
I
think
+1
on
G
RPC
on
that
I.
Think
the
nice
thing
about
your
PC
is
you
don't
have
to
worry
about
how
to
generate
client
code,
the
length
that
the
juror
PC
framer
is
going
to
generate
the
client
for
you
and
it's
generally
client
for
every
single
language
and
I,
for
example,
Python
like
do
we
have
a
binding
for
Python,
probably
not
right
now,
and
it's
under
maintained
its
I?
Think
by
switching
to
like
a
common
like
RPC
framework
like
to
your
PC.
We
don't
have
that
issue
anymore.
H
That's
one
towards
you
said:
I
think
I
think
both
the
things
uber
maintains
the
talks
to
mezzos,
as
well
as
any
other
program
language
over,
which
is
not
the
regular
talk
on
the
bezel,
yet
all
have
proper
givg
bindings.
So
this
would
mean
we
can
simply
get
rid
of
all
the
late
of
this
layer
of
like
an
interesting
part
of
the
interaction
with
metals,
direct
library
and
the
folks
read
on
the
logic
part
right.
D
I
think
like
for
for
some
language
that
I
know,
for
example,
go
I
know
there
are
a
few
bindings
out
there
there's
and
mazes
go
there's
some
other
binding
I
think
they're
mighty
moe's
we'll
go
binding
there,
but
no
don't
is
properly
maintained.
Well,
like
maces.
Go
is
maintained
by
James
on
from
mrs.
fear,
but
I'm
not
sure
about
other
bindings,
but
still
like
it.
It's
if
you
compare
to
a
generic
line
like
grr
PC
is
to
like
much
prefer.
I
mean
I.
C
D
Well
need
to
get
some
data.
I
mean
I'm,
not
sure
that
if
goober
is
using,
oh
sorry,
I
mean
shoot
I'm,
not
sure.
If
uber
is
your
PC
that
do
you
have
real
data
to
show,
like
anything
that
you
sure
I've
got
the
performance
of
your
PC
like
on,
like
in
terms
of
like
the
latency
or
I,
tell
latency
999
latency
things
like
this
I.
H
Don't
have
that
data
here,
but
what
I
can
say
is
our
RPC
team
is
encouraging.
Is
slowly
encouraging
people
to
move
from
our
own
stops,
I
mean
kotti
Channel
I'd,
rather
thrift
I'll
to
GRDC,
slowly
so
I
think
from
the
oh.
We
all
go
heavy
firm,
so
I
think
they
only
do
perform
testing
for
the
go
part.
Both
the
server
and
the
client
I
don't
know
about
how
this
comparator
the
other
languages
so
far,
yeah.
D
I
think
Jeff,
you
see
cool
yeah,
I,
think,
okay,
yeah
I,
think
I
have
some
data
on
like
the
juror
PC
performance
will
be
useful
on
to
to
to
to
kind
of
answer.
I
think,
like
I,
heard
some
concern
about
folks
talking
about
a
low
latency
about
your
PC
framework
and
they
want
predictable
performance
things
like
this,
but
it's
what
we
don't
have
really
real
data
to
show
that,
but
I
think
my
performance
might
be
a
less
of
a
concern.
I
think
it's
more
about
API
and
like
a
nice
API,
RPC
framework.
B
D
D
Think,
like
there's,
no
alternative,
like
I
think
I
mentioned
to
teach
you
like,
there's
some
other
RPC
frameworks
like
be
RPC,
but
I
think
I
will
be
worried
about
the
maintenance
like
who
isn't
maintain
that
repo,
like
is
get
good
support,
I,
mean
I,
mean
sure.
Pc
got
a
huge
community
behind
that,
so
I
think
I
really
don't
see
an
alternative
to
your
PC.
At
this
moment,
yeah.
H
I
think
the
I
think,
if
he's
three
years
ago,
I,
would
try
a
thrift
a
little
bit,
but
even
now.
Well,
our
company
has
migrated
modern
how
the
things
on
to
thrift.
We
have
slowly
to
migrate
off
of
it
for
a
new
stuff
so
and
I
think
B
RPC
do
not
have
only
have
seen.
I
only
heard
that
they
have
see
puzzles
by
being
even
Java
is
not
really
yet
yeah.
D
I
think
I
a
briefly
look
at
the
RPC
yeah
that
the
number
of
bindings
compared
to
your
PC
is
small.
B
Yeah
I
think
we
think
there's
an
alternative
either
I
just
don't
want
to
be
debugging,
mysterious,
chair,
PC,
bugs
and
and
and
trying
to
diagnose
performance
issues.
That's
kind
of
my
main
thing,
but
if
we
let
companies
try
it
out
the
people
with
large
installations,
try
it
out
and
then
tell
us
what
doesn't
work
performance
wise.
Then
that's
less
of
a
issue.
I.
H
H
D
D
I
I
can't
reach
out
to
lift
folks.
Thank
you,
okay.
My
question
is
like:
what's
the
plan
at
the
working
group
like
we
have
a
bunch
of
people
that
trying
to
work
on
this
and
I'm
interested
I'm,
not
sure
if
anyone
else
is
interested
interested
in
GRP,
see
specifically
yourself,
yeah.
Okay,
like
how
do
we
work
together
to
get
that
done,
I
mean.
B
Hope
with
v2
is
that
we
would
clean
up
unfortunate
decisions
in
the
API,
but
we
currently
aren't
doing
anything
to
actually
keep
track
of.
It
was,
and
so
what's
likely
gonna
happen
with
v2.
Is
we
don't
clean
things
up
and
we
just
kind
of
copy
everything
over
which
would
seem
unfortunate
to
me,
and
so
we
need
some
process
or
something
to
you,
an
audit
of
what
we
have
and
try
remember
all
the
the
things
that
we
find
it
unfortunate
and
want
to
change.
B
D
Yeah
I
think
bender,
like
I,
think
there
are
like
three
questions.
One
is:
how
do
we
track
those
tech
debt
on
API
that
we
want
to
clean
up
in
the
next
major
version?
I
think
maybe
one
solution
just
use
the
label
sound
and
then,
whenever
you
find
something,
that's
unfortunately
screen
and
JIRA
and
in
your
special
label
there-
and
this
is
the
label
name
here,
so
that
we
can
track
those
that's.
That
was
just
my
suggestion
on
that
issue.
The
second
issue.
D
The
second
question
is
whatever
you
want
me
to-
should
be
backwards,
compatible
I,
feel
like
it
should
not
by
by
definition,
issue
not
and
I
think
we
should
definitely
allow
us
to
do
some
breaking
changes.
We
meet
you
so
that
we
can
clean
up
those
unfortunate
api's
that
we
introduced
in
the
codebase
and
the
third
problem.
The
third
issue
is
whether
the
gr
PC
support
should
be
in
v2
or
in
v1.
So
that's
something
that
I
haven't
figured
out
like
like.
Is
it
possible
to
still
like
this
is
possible?
D
D
That's
that's
more
like
a
question:
I'm,
not
sure
what
other
folks
are
thinking.
My
hunch
is
like
how
the
rather
like
move,
faster
and
kind
of
introduced
like
your
PD
support
for
v1
protobufs
and
then
at
the
same
time,
thinking
about
what
we
should
do
for
beats.
You
I
mean
that
the
nice
thing
is
you
get
some
experience
when
you're
building
that
support,
and
we
don't
want
to
like
that
rush,
we'll
beat
you.
C
D
C
D
C
C
D
Well,
yeah,
that's
just
my
thoughts
that
we
should
not
wait
until
v2
to
do
G
RPC
and
we
should
be
very
cautious
on
I
mean
given
what
been
set
is
that
we
have
a
lot
of
tech
data
on
the
API
that
we
need
to
clean
up,
and
we
part
need
to
collect
those
and
make
sure
that
our
v1
sorry
v2
API
kind
of
address
on
the
tech
data
we
have
rather
than
just
leaving
those
tech
there
forever
in
the
codebase.
Yeah
I
mean.
D
E
D
D
D
B
C
D
C
C
No
okay,
well
I,
really
appreciate
everyone
showing
up
it's
great
to
have
our
first
meeting
I
will
send
out
an
email
to
the
mailing
list,
just
sending
out
the
notes
and
we
will
have
another
meaning
in
two
weeks.
Oh
I
guess
should
have
asked
before
just
this
time
generally
work
pretty
well
for
everybody.
Is
there
anyone
who
objects
to
this
time
as
a
recurring
time.
H
For
me,
okay,.