►
From YouTube: GraphiQL Working Group - 2022-10-11
Description
GraphQL is a query language for APIs and a runtime for fulfilling those queries with your existing data. GraphQL provides a complete and understandable description of the data in your API, gives clients the power to ask for exactly what they need and nothing more, makes it easier to evolve APIs over time, and enables powerful developer tools. Get Started Here: https://graphql.org/
D
Nice,
it's
going
well
here
too
I
I
finally
managed
to
join
one
of
these
there's
always
like
conflicts
happening
yeah
today
and
like
on
this
day,
so
yeah,
hopefully
in
future,
we'll
be
able
to
join
more
often.
C
A
B
It's
Thomas
he's
not
here
like.
C
A
In
the
meantime,
here's
John
foreign.
A
In
the
meantime,
I've
prepared
a
Google
sheet
where
we
can
take
some
notes.
We
actually
don't
have
any
agenda
yet,
which
would
be
the
first
thing
to
come
up
with
one
and
also
heads
up.
I
certainly
have
to
leave
in
half
an
hour,
because
I
have
another
meeting
that
I
can't
miss.
Sadly,
just
so
that
you
know,
if
I'm
dropping
out.
A
Maybe
while
we
wait,
we
can
already
get
to
some
agenda
items
if
you
have
brought
any
I
would
like
to
quickly
allow
that
quickly.
I
would
like
to
align
on
what
our
next
bigger
efforts
around
graphical
are
just
on
a
high
level
that
we
all
know
that
we
pull
on
the
same
stream,
basically
also
kind
of
a
preparation
to
finally
go
into
our
issues
on
the
repository
and
to
clean
that
up
and
create
a
roadmap
that
we
all
align
on.
A
A
Let's
get
going
then
see
if
anybody
joins
Nicole,
but
won't
wait
any
longer.
Maybe
let's
also
since
I,
don't
know
everybody
in
this
room
that
started
a
quick
intro
so
that
we
all
get
to
know
each
other
a
bit
better.
I
can
also
start
hey
Doc's,
also
coming.
A
A
We
were
just
about
to
get
started
quick
round
of
intros
so
that
we
get
to
know
each
other
in
the
I'm
Thomas,
making
it
still
late
rugby
a
lot
on
graphical
too
and
yeah.
Maintaining
graphical,
no
sleep
right
now,.
E
Okay,
I'll
go
I'm,
John
I
live
in
Austin
Texas
I'm,
a
product
developer,
foreign
ly
not
working,
took
a
year
off
looking
to
get
back
into
work
soon,
but
in
the
last
six
months
or
so
I've
been
spending
a
lot
of
time
on,
like
future
graphical,
primarily
the
new
visual
query:
Builder,
there's
a
there's,
a
it's
a
real
rat's
mess
of
like
design
interaction
problems,
so
most
of
the
time
has
been
spent
there.
If
you've
seen
the
Prototype
that
I've
been
working
on.
E
There's
there's
also
a
lot
of
like
Monaco
bits
that
have
been
trying
to
figure
out
and
it's
it's
nice
to
meet.
You
Tim
and
Doc.
Welcome.
C
B
Sanko
I'm
Tim
I'm
in
Virginia
U.S
working
at
postman
on
our
Labs
team.
That's
focused
on
graphql
at
the
moment,
so
a
lot
of
client-side
work,
integrating
graphical
and
seeing
how
I
can
help
out
here
and
give
back
do
all
that
stuff.
Thanks
Doc
for
connecting
me
to
these
fine
folks.
F
So
my
name
is
Doc
I
work
for
a
group
inside
of
Postman
called
open
Technologies
and
we
focus
on
open
source
development.
We
support
five
specs
open,
API,
async,
API,
graphql,
Json,
schema
and
grpc,
and
we
support
them
financially,
as
well
as
with
engineering
resources.
F
My
focus
I'm,
the
the
graphql
lead
in
open,
Technologies
and
so
I
work
on
graphql
sort
of
different
aspects
of
the
ecosystem
all
day
every
day
and
I
am
so
excited
about
the
new
active
development
in
graphical
so
I'm
here
to
to
see
how
I
can
help.
D
I
guess
it's
me:
I'm
Patrick
I'm,
a
developer,
advocator
and
I,
mostly
maintain,
which
is
a
python
Implement
python
implementation,
biographical,
server,
yeah,
I'm
interested
in
basically
helping
out
really
graphical
and
also
like
you
know,
making
I
guess.
One
goal
I
have
now
is
like
making
it
easier
for
libraries
to
integrating
and
also
customize
them,
for
example,
where
you
can
have
a
custom
team
and
for
the
libraries
kind
of
down
team.
These
kind
of
things.
A
All
right
awesome,
thank
you
very
much
again
feel
free
to
add
another
bunch
of
agenda
items.
If
you
have
something
that
you
would
like
to
talk
about,
given
that
there's
nothing
in
there,
oh
by
the
way,
I
think
I
have
to
share
the
link
again
for
first
training
later
I
opened
a
Google
doc
for
note-taking
okay,
first
time
in
there
there's
nothing
else.
A
I
would
start
with
the
one
that
I'm
bringing
which
is
basically
aligning
on
the
efforts
that
will
like
the
bigger
Milestones
that
we
want
to
hit
for
graphical
in
the
upcoming
months
and
I
can
start
by
sharing.
What's
on
my
mind
and
I'm,
just
hoping
that
we
can
have
a
discussion
around
this
and
also
very
interested
in
your
perspectives
that
you
bring
into
this
the
two
big
sorry.
This
did
anybody
want
to
say
something:
okay,
I'll
just
continue.
A
The
two
bigger
topics
that
I
see
are
on
the
one
side,
one
Echo,
which
we
didn't
do
with
version
two
but
postpone
until
later,
which
also
John
has
been
working
like
your.
Your
prototype
has
been
using
Monaco
from
the
start,
so
that
was
like
a
very
good
way
of
already
validating
that
it's
use.
The
Monaco
graphql
part
is
actually
usable
yeah,
so
that
would
be
one
bigger.
E
Idea,
sorry
I
think
that's
that's
sort
of
where
just
to
catch
everybody
up
quickly,
that's
where
the
Prototype
and
Monica
that's
sort
of
where
it
stops.
It's
it's
usable!
It's
the
right!
It's
a
it's
a!
We
can
do
it,
but
there's
there's
still
a
load
of
stuff
to
figure
out
there.
It's
validated
basically.
A
Yeah,
probably
still
an
effort
to
get
it
into
shape
for
actually
being
then
feature
complete
and
be
usable
in
graphical,
but
I
think
it's
it's
enough
to
get
started
and
actually
start
the
effort
on
this
front,
and
the
other
thing
I
see
is
the
also
which
John
pioneered
in
his
in
his
prototype,
the
visual
query,
Builder
or
doc,
Explorer
or
monograph
Explorer
version
2.
However,
you
want
to
call
it.
A
A
I
think
would
be
actually
like
if
we,
if
we
get
it
into
shape,
it
would
probably
be
another
major
version
for
graphical
because
it
brings
I
think
also
some
changes
around
how
you
build
and
run
graphical
Monaco
is
at
least
recommended
to
run
in
that
workers,
which
is
something
that
karma
is
just
just
not
even
possible.
So
there
would
be
some
breaking
changes
around
graphical
coming
with
Monaco.
A
Probably
the
visual
operation
Builder,
on
the
other
hand,
could
be
something
that
might
be
possible
or,
like
we
have
the
the
new
plugin
APR
now
in
version
two.
A
So
this
is
basically
a
a
starting
price
for
trying
to
integrate
something
like
this,
but
probably
this
plugin
API
would
need
to
also
get
more
powerful,
because
it
was
very,
very
simple
for
now,
which
was
also
intentional
for
version
two
to
keep
the
scope
a
bit
narrower,
but
we
would
probably
need
to
expand
on
this
front
as
well,
which
is
currently
at
least
for
me
still
a
set
of
unknowns.
E
Yeah
I
think
the
I
think
you're
right
about
the
plug-in
API
needing
to
be
a
little
more
fleshed
out
and
solid,
but
we
already
have
sort
of
agreed
that
that's
a
path
forward
for
us
right.
So
that's
not
new
information,
the
so
the
I
think
it's
interesting
that
Monaco
and
the
visual
operation
Builder
were
left
out
of
V2
I.
Think
that
now
three
months
ago,
I
didn't
think
that
I
thought
well.
Those
are
kind
of
like
the
big
you
know
other
than
like
the
new
skin.
E
Those
are
like
these
are
the
two
big
things
right.
We
all
know
that
one
grass
Explorer
the
take
up
right
across
graphical
installations
is
probably
in
the
majority
I
think
the
majority
of
them
are
are
running
exploring.
So
it
was
a
big
feature
to
get
to
get
in
so
but
now
I
now
I
think
I
know
why
and
and
it's
because
the
decision
to
go
to
Monaco
is
not
just
a
decision
to
switch
to
Monaco.
It
includes.
E
Do
we
I
also
I,
don't
have
edit
access
to
the
document
Thomas,
so
I
couldn't
make
these
notes
in
there
thanks
for
the
call
out,
but
this
the
the
decision
isn't
about.
Do
we
replace
code
mirror
with
Monaco
anymore,
that
that's
I
think
that's
the
way
that
it
used
to
be.
E
It
was
going
to
be
a
replacement
now,
there's
another
there's
a
there's
another
there's
thinking
that
we
might
have
two
modes
right,
you
you
could
use
code
mirror
if
you
want
to,
you
could
use
Monaco
if
you
want
to
and
I
think
as
a
group,
we
need
to
make
that
decision
before
we
do
anything
else,
because
if
we're
gonna
go
through
the
exercise
of
building
out
the
visual
operation
Builder,
we
really
need
to
Target
one
of
those
editors,
because
it's
from
what
I
can
tell
I,
don't
have
a
lot
of
code
mirror
experience,
but
from
what
I
can
tell
to
do
it
correctly
with
the
right
experience
is
just
a
vastly
different
way
of
it.
E
You
know
inserting
edits
into
the
editor.
It's
just
it's
a
lot
different
the
surface
to
connect
the
visual
operation
Builder
to
the
store
for
the
editors
for
the
operation.
Editor
would
just
it
seems
to
me
like
it
would
be
radically
different,
so
code
mirror
and
Monaco,
or
just
code
mirror
or
just
Monaco,
like
there's
timing
and
scheduling
that
we
need
to
figure
out
there
and
then
out
outside
of
the
like.
What
editor
are
we
going
with
discussion?
The
visual
operation
Builder?
E
There's
not
a
lot
of
it's
It's,
Tricky
technology,
wise,
but
it's
way
more
complicated
interaction,
wise
there
are
there's
lots
of
prior
art
who's
done
it.
This
way,
who's
done
it
that
way.
I've
spent
a
lot
of
time.
The
last
week,
looking
at
Apollo
sandbox
and
how
they're
doing
things
there's
a
there's,
a
there's,
a
right
combination,
approach
for
graphical
that
represents
spec
compliance
and
is
also.
E
Familiar
to
the
way
that
people
are
already
using
these
jumble
of
tools,
you
know
one
of
my
one
of
the
things
I
would
like
to
see
with
graphical
is
just
to
to
bring
back
into
the
fold.
Some
of
the
users
that
have
left
for
alternative
tools
and
I
think
nailing.
The
visual
operation
Builder
is
is
a
is
a
is
a
real
big
one.
E
So
that's
primarily
a
design
exercise,
lots
of
tech
sure,
but
getting
the
interactions
right,
you
know,
is
going
to
be
the
most
important,
especially
in
this
setting
where
most
of
our
common
conversations
happen,
async
right
and
people
kind
of
come
and
go
from
discussions,
whether
it's
Discord
or
from
the
GitHub
discussions.
People
come
and
go,
and
we
just
don't
have
a
program
to
validate
all
of
the
different
micro
interactions
for
the
visual
operation
Builder,
and
there
are
many
that
need
to
get
figured
out.
E
So
that's
a
rambling
way
of
saying
that
I
think
we
could
execute
the
visual
operation
Builder
sooner
rather
than
later.
We
just
we
need
to
figure
out
the
design
stuff
like
it.
We
need
to
be
find
a
program,
a
way
to
manage
the
program
to
flush
that
stuff
out.
A
All
right
also
for
Patrick
talk
and
Tim.
What
are
your
perspectives
on
these
like
two
topics,
or
do
you
have
maybe
additional
things
that
you
think
are
important
for
Graphica.
D
Well,
I
think
the
the
points
that
John
was
was
was
was
making
I
think
are
quite
important,
especially
on
the
kind
of
plug-in
part
I.
Think
like
graphical
is
gonna
succeed.
I
think
it's
gonna
be
one
of
the
best
studies
experience.
If
we
have
plugins
I
can
see
like
a
world
where
people
have,
even
you
know,
for
your
own
company
having
a
plugin
that
works
for
you,
things
like
maybe
just
code
gen
things
like
that.
D
It
would
be
amazing
to
have
something
like
that
and
I
think
we
might
I
don't
know
I
feel
like
there's
gonna
be
some
plugins
that
are
gonna
like
reach
out
into
the
editor
and
I
think.
Maybe
we
should
kind
of
move
on
with
that
and
decide
what
we
want
to
do.
It's
either
we
kind
of
move,
we
choose
Monaco
and
then
we
get
like
plugging
completely
access
to
Monaco.
E
I
agree
that
running
dual
a
dual
setup:
there
is
that
layer
is
not
that
wouldn't
I
wouldn't
want
to
do
that.
I
wouldn't
want
to
work
complicated.
F
F
Also,
a
monocle
Monaco
editor
that
I
would
really
vote.
I
I
personally
would
vote
to
go
Monaco
only.
G
I'm
glad
people
love
the
plug-in
API
design.
It
was
years
in
the
making
we
crafted
it
from
user
needs
and
it's
amazing
to
see
it
in
place
now
and
it's
just
the
beginning
of
what
we'd
imagine,
but
it's
like.
So
it's
it's
starting
to
fall
into
place.
Yeah
and
the
the
code
exporter
plug-in
is,
is
almost
done
and
there's
more
coming.
So
I
have
another
plug-in
that
I'm
about
to
introduce
as
well
so.
F
Foreign,
so
that
was
a
question
that
I
had
is
like:
will
will
plug-ins
and
graphical
ever
be
like
user
selected,
or
will
the
implementer
always
be
in
charge
of
what
plugins
are
available.
G
We
discussed
this
a
few
years
ago
and
we
decided
that
we
would
first
make
it
so
that
you
like
set
them
up
when
in
props
and
ideally
in
a
bundler
at
first
just
because
it
made
it
easier
to
get
it
out
the
door
and
get
it
to
like
a
2.0
like
we
are
now,
but
eventually
for
later
major
version
iterations,
we
would
love
to
explore
those
kinds
of
capabilities.
G
We
need
to
strike
a
balance,
of
course,
and
that's
why
we
want
the
SDK
route,
because
we
need
a
simple
editor
for
spec
development
for
some
more
simpler
uses,
and
then
we
also
need
a
more
in-depth
capability
for
everyday
usage
and
real
world
applications
as
well.
So
it's
this
allows
us
to
kind
of
yeah
explore
different
approaches.
There
I
feel
like
plugins
could
be
a
great
part.
My
original
idea
was
that
there
would
be
graphical
would
be
a
component
on
its
own
and
then
there
would
be
a
plug-in
management
like
rapper
component.
E
E
Right
so
so,
right
after
that
happened,
I
think
there
was
a
lot
of
enthusiasm
and
conversation
around
a
you
could
just
Google
for
playground.
Dash,
preset
and
you'll
find
all
the
stuff
their
enthusiasm
for
having
like
a
version
of
graphical,
that
sort
of
contained
all
of
that
extra
all
those
extra
bits.
So
you
you
could
think
of
graphical
as
having
two
modes
right.
There's
like
the
bass
mode,
which
is
scratch
Pad
right.
E
It's
full
spec,
compliant
scratch
pad,
and
then
there
was
another
version
that
had
a
lot
more
surface
exposed
and
that's
like
the
the
playground
reset
I
again
like
the
naming,
the
things
get
confused
with
the
naming
right,
because
playground
has
a
lot
of
connotations
to
it
like
it
needs
to
be
something
else,
but
something
like
a
little
more
like
Drop
in
ready
to
go
all
the
bits
likely.
E
You
know
fully
extensible
and
and
fully
documented,
so
I
think
there's
a
lot
of
it.
There's
a
lot
of
it's
really
interesting
that
we
might
have
sort
of
two
modes.
Of
course
it
increases
complexity
and-
and
we
you
know
it
would
be
nice
to
have
a
lot
more
bodies
here.
Working
on
the
stuff
for
sure.
G
Yeah
I
think
the
SDK
affords
us
a
lot
of
flexibility
here,
even
moving
forward
through
major
version
iterations,
so
I
think
it's
also
possible
that
we
could
just
have
a
mini
graphql
component
that
that
achieves
this
goal
of
like
a
more
scratch.
Pad
type
editor
experience
like
sandpack
I,
think
is
a
great
prior
art,
and
that
was
in
some
of
the
original
ux
or
well.
G
Some
ux
sketches
I
made
last
year
or
this
year
was
just
like
a
simple
idea
of
like
simple
embeddable
editors
and
we
can
ship
more
types
of
simple
components:
I
think
from
the
SDK
as
well.
That
are
just
like:
hey
here's,
a
great
starting
point
for
like
a
embedded,
docs
editor
and
it
works.
When
you
embed
multiple
components
on
the
same
page,
so
you
can
scroll
through
and
depending
on
which
one
your
hover
your
active
over.
F
So
John
I
don't
know
how
many
people
you
were
thinking
of
like
additional
people
showing
up,
but
there
are
additional
people.
It's
my
understanding
that
there's
some
folks
from
The
Guild,
who
couldn't
be
here
today
because
they're
in
Sprint
planning,
but
they
have
stated
their
intention
to
start
contributing
to
graphical
they'll,
be
watching.
G
F
They
want
yeah,
they
want
it,
they're
ready
to
the
I
think
the
phrase
was
re-engage
with
graphical,
so
they
want
to
put
some
effort
into
the
project
again.
The
other
reason
they're
not
here
is
because
they
had
their
own
Sprint
planning
scheduled
at
the
same
time.
Otherwise
they
would
have
been
here.
C
C
G
A
Right
to
summarize
I
hear
that
both
the
plugins
is
one
thing
that
is
like
the
most
interesting
part
around
graphical
right
now
and
I
hear
that
we
either
need
like
in
combination
with
the
efforts
around
Monaco.
We
either
need
to
like
now
move
to
Monaco
and
allow
plugins
to
only
Target
that
editor
or
we
need
some
kind
of
abstraction
layer
above
editors
that
allow
plugins
to
interact
with
the
editors
without
being
specifically
targeting
code,
neural
or
Monica,
because
that
would
make
it
not
feasible
writing
targets
maintaining
to
different
editors.
G
Yeah
yeah,
we
have
a
code,
mirror
6
mode
ready
to
publish.
We
just
need
to
get
one
final
approval
on
it
that
Samuel
from
yeah
right,
yeah,
Altair
yeah.
So
we
have
the
code,
mirror
six
mode
ready
fully
Rewritten.
G
So
we
have
both
one
for
both
five
and
six
now,
but
I
think
we
could.
It
still
makes
sense
to
move
to
Monaco
for
three
and
then
maybe
we
decide
how
to
introduce
support
in
the
SDK
for
code
mirror
6
without
necessarily
having
to
introduce
it
to
graphical
three
or
four
for
that.
Even
for
that
matter
right,
so
we
could
say:
well,
if
you
want
to
use
code,
mirror
6,
you
can
use
the
SDK
because
the
SDK
supports
it.
Maybe
we
create
another.
G
A
special
SDK
package
just
for
code
mirror
6,
for
example,
and
then
people
and
some
examples
and
give
people
a
good
starting
point
there
if
they
want
to
use
that
it
might
be
better,
for
example,
for
for
accessible
light
lightweight
documentation,
preview
type
user
experiences
would
be
great
for
because
Monaco
is
just
always
going
to
be
a
little
bit
bulkier,
which
is
fine
for
more
in-depth
IDE
type.
Experiences
but
I
I
think
yeah.
G
F
So
what
when
do
you
expect
to
release
3.0.
A
That's
a
very
good
question:
I!
Don't
currently
dare
to
give
an
time
estimation
here:
I
haven't
worked
with
Monaco
too
too
much
myself.
I
was
really
focusing
on
the
design
parts
and
yeah
getting
these
two
out
of
the
door.
A
So
I
can't
estimate
it.
I
don't
know
if
somebody
else
dares
to
give
an
estimation.
G
E
Yeah
I've
been
working
full
time
on
this
for
about
six
months
and,
like
I,
said
Ricky
I,
don't
know
if
you
caught
this
early
early
bit
or
I
was
saying
that
the
Monaco
stuff
that
I've
done
up
to
now
is
just
validating
that,
like
it
works
like
it
does
a
thing,
it's
great
there's
a
ton
of
infrastructure
around
it
that
needs
to
get
built,
and
that
is
more
complicated.
E
When
you
try
to
build
a
plug-in
like
the
visual
operation
Builder,
where
you
want
to
slice
the
updates
into
the
editor
I,
don't
know
exactly
how
code
mirror
works,
but
I
think
it's
different
than
the
surgical
updates
to
the
values
that
are
in
the
Monaco
editor
years
and
for
the
last
five
days,
I
have
been
in
absolute
hell,
trying
to
figure
out
how
to
make
surgical.
Monaco
editor
updates
work.
It's
not
my
forte!
E
That
kind
of
work
so
five
days
not
being
able
to
figure
out
a
smarter
engineer
likely
could
have
done
it
faster,
but
there
is
a
load
of
work
that
needs
to
get
done
to
figure
out
for
something
like
the
visual
operation
Builder,
where
you're
not
just
throw
you're,
not
building
a
brand
new
value
and
pushing
it
into
the
editor
to
display
there's
a
lot
of
work
that
needs
to
get
to
get
done
there
and
I
think
it's
going
to
be
different
between
code
mirror
and
Monaco.
I
think
those
are
going
to
be
radically
different
situations.
E
E
Yeah,
so
to
go
back
to
the
question
doc
of
like
providing
an
estimate,
I
think
both
Thomas
and
Ricky
and
myself
are
all
agreed
that
it's
it's
a
question
mark.
Until
until
we
can
we,
we
can
have
folks
that,
are
you
know
focusing
on
what
that
below
what
that
necessary
velocity
is
going
to
be,
and
then
we
can
say
like
here's,
here's
a
Target
date
for
for
when
that's
going
to
happen.
C
F
Just
the
reason
I
was
asking:
that
is
because
this
idea
of
pushing
Monaco
out
to
3.0
just
lays
it
on
the
table
right,
you're,
just
walking
away
from
it
and
I
would
like
to
see
Monaco
come
about
much
sooner
than
3.0,
like.
G
A
Okay,
but
it
sounds
like
then
Monaco
is
the
clear
thing
to
focus
on
and
to
drive
alignment
which
isn't
something
that
has
to
happen
now
in
this
meeting
completely
but
like,
let's
say.
A
So
the
thing
to
focus
on
for
us
when
we
get
try
to
get
the
roadmap
into
shape,
also
to
work
out
a
key
apart
towards
Monaco
and
also
to
find
people
who
are
willing
to
contribute
to
that
and
yeah
then
start
basically
assigning
the
work.
It
starts
more
or
less
the
exploration
to
get
the
announce
out
of
the
door.
D
E
E
Was
was
was,
was
picking
there,
I
think
Patrick's.
Maybe
one
thing
that
we've
talked
about
previously
is
going
to
the
the
larger
graph
graphql
working
group
and
saying,
like
graphical,
has
a
plan.
We
just
need
bodies,
hey
y'all,
you
know.
Are
there?
Are
there
people
that
you
that
you
wanna
that
that
I.
G
Have
that
we
might
have
like
a
a
set
of
people
who
have
a
lot
of
Monaco
experience.
Who've
worked
on
the
vs
code
team
who
have
contributed
to
Monaco
graphql
that
we
can
talk
to
who
who
have
shown
interests
and
who
have
contributed
and
who
would
be
happy
to
help.
Just
let
me
know
and
like
these
are
people
that
have
already
been
involved.
They've
already
contributed
and
they're
already
using
Monaco
graphql
at
work.
G
You
know
so
like
they're,
already
using
it
at
Airbnb
they're
using
it
at
Fire
camp,
there's
a
bunch
of
companies
using
Monaco
graphql,
so
those
would
be
the
best
people
to
talk
to
and
most
of
them,
the
issues
we're
working
on
have
to
do
with
real-time
sdl
development.
G
B
G
Well,
I
mean
anyone
who
wants
to
help
like
we
need
more
people
to
learn
about
it
as
well
I'm,
just
saying
if
we
want
people
who
want
to
be
become
to
develop
expertise
in
this
area.
That
would
be
awesome,
but
you'll
have
to
be
very
patient
because
it
is
Monaco
is
not
it's
not
as
well
documented
and
there's
a
lot
of
ways
to
like
learn
how
to
work
with
the
Monaco
apis.
But
it's
it's
not
it
like.
G
It
requires
mentorship
and
I
would
like
to
make
sure
that
people
have
good
mentorship
and
doing
that
and
I
don't
want
to
see
people
like
starting
over
from
scratch
and
that's
what
I
was
worried
about,
because
I
get
this
sometimes
where
people
are
like
hey
Ricky.
Do
you
know
someone
who
knows
how
this
Monaco
thing
works
and
it's
like
well
I
created
it
like
I
kind
of
know
how
it
works.
G
You
know
so
I'm
happy
to
help,
but
like
there's
others
who,
who
know
quite
a
bit
as
well,
but
there's
a
lot
of
people
who,
who
built
a
lot
of
knowledge
just
by
themselves
and
just
the
way
I
did
or
just
they
just
taught
themselves
and
then
and
we
can
all
teach
ourselves
more
about
the
Monaco
apis
and
Monaco
language
modes,
which
are
not
like
other
Monaco,
plugins
or
Integrations
they're,
very
with
the
workers,
and
everything
like
that
so
but
I'm
happy
to
help
with
that
and
I'm
very
open
to
architect.
G
Proposals
for
architectural
changes
there's
a
lot
of
things.
I
want
to
do.
I
want
to
use.
You
know,
index
DB
to
sync
schema
between
the
workers
and
the
main
process
to
make
it
more
efficient
and
to
make
it
so
that
you
can
cache
schemas
between
browser
tabs.
Can
you
guys
hear?
Can
you
all
hear
me
background.
E
A
G
Yeah
so
that
they
can
cache
the
schema
State
between
tabs,
which
is
had
because,
basically
because
of
this
issue
with
real-time
schema
development,
where,
as
you're
editing
the
schema,
then
it
keeps
creating
the
web
workers.
So
there's
there's
a
there's
a
lot
of
improvements.
We
can
add
to
Monaco
graphql
that
will
make
things
easier
and
we'll
address
some
of
the
issues
Upstream
that
that
people
have
been
running
issue
running
into
there's,
multiple
open
bugs
to
fix
with
Monaco
graphql
stove,
and
whoever
wants
to
work
on
that.
G
Let
me
know-
and
maybe,
if
we're
lucky,
we
can
get
some
people
from
the
vs
code
team
to
give
us
some
pointers
on
things
because
they're
very
enthusiastic
about
this
mode.
But
we
don't.
We
won't
need
their
help
necessarily
to
accomplish
anything
either
and
I.
Think
Christine,
shaver
is
a
great
person
to
talk
to
I,
in
fact,
will
probably
make
her.
I
was
planning
to
make
her
a
maintainer
and
with
her
Focus
being
on
Monaco
graphql
and
from
the
The
Real
World
experience
at
Airbnb
there.
G
So
her
team's
been
working
with
it
a
lot
and
she
has
a
lot
of
ideas
for
how
to
improve
it
so
but
yeah.
Anyone
who
wants
to
specialize
in
that
area
that
would
be
awesome,
yeah
and
I
would
love
to
help
and
I
also
started
over
just
looking
at
the
Monaco
API
docs
like
how
does
this?
How
does
this
work?
It's.
E
Really
bad
the
I
I
want
to
make
a
special
note
about
what
you
said
about
mentorship
I
wrote
in
the
doc,
I
think
learning
Monaco
on
your
own.
Is
it's
not
fun?
It's
not
a
pleasant
thing
to
do
it
really
isn't
it's
not,
and
so
the
the
idea
of
mentorship,
specifically
like
in
that
vertical
that
thing
that
we're
doing
I
think
is
great.
E
If
there
was
a
way
that
we
could
flag
certain
people,
as
you
know
already
having
the
knowledge
that
that
could
be
direct
sources
and-
and
we
could
you
you
know,
we
could-
you
know,
publish
that
we
could
socialize
that
a
little
bit.
It
would
be
very
helpful.
Those
are.
F
Yeah
I
think
it
would
be
a
good
idea
too,
to
to
have
people
that,
like
if
they're
you
know
if
you're
available
for
for
mentorship.
You
know,
let's,
let's
you
know
like
tag
you
that
way
or
tag
an
issue
that
you're
willing
to
Mentor
on
or
give
like.
You
know
if
there's
some
general
level
of
mentorship
that
you
would
prefer
to
do.
You
know
how
to
how
to
communicate
with
you
about
that.
Do
you
want
email?
Do
you
want
to
talk
in
Discord
How?
G
And
that's
that's
a
great
question
and,
for
example,
for
Monaco
graphql,
just
ping
me
in
the
Monaco
graphql
channel
on
Discord
and
I'm
happy
to
start
a
conversation,
help
you
track
something
down,
but
oftentimes.
It
comes
down
to
scheduling
like
some
pairing
or
time
and
and
I
think
it
would
be
cool
to
turn
that
into
a
regularly
like
recorded
thing
that
we
could
share
with
others
async
as
well.
So.
G
Exactly
yeah
I
actually
had
originally
announced
Monaco
graphql
office
hours
in
like
2020
and
just
I,
don't
know
some
things
happened
that
year
it
was
hard
to
queue
to
the
schedule,
but
I
think
I
could
it'd
be
easier
to
keep
two
now
yeah
yeah.
E
I
know
I
want
to
reiterate
that
again,
just
based
on
my
experience,
the
last
you
know
few
months,
the
the
Monaco
challenge
is
not
about
Monaco
graphql,
it's
about
Monaco,
if
self,
that's
where,
like
that's,
where
the
heavy
lift
is
I,
have
plenty
of
thoughts
and
and
and
ideas,
and
questions
about
Monaco
graphql
like
how
to
tokenize
properly
lots
of
stuff.
E
But
the
big
effort
is
just
like
the
AP,
the
just
the
difficulty
around
the
API
surface
and
the
documentation
and
the
fact
that
they
don't
have
discussions
on
their
GitHub,
which
is
just
absolutely
like.
It's
nightmarish
that
they
don't
that
they
haven't
unlocked
discussions,
because
it's
all
issues
and
it's
just
kind
of
chaos.
So
that's
where
the
the
the
bulk
of
the
lift
does
anybody
have
any
other.
E
So
we're
talking
about
the
the
two
big
efforts
for
the
near
future?
Right,
that's,
that's!
Monaco!
That's
the
visual
operation,
Builder
sort
of
underlying
that
is
the
the
criticality
of
a
more
foundational
plug-in
experience
that
I
don't
know
that
we
have
I,
don't
know
that
we
can
separate
that
in
a
way
that
makes
a
lot
of
sense.
I
know
that
there
have
been
conversations
in
the
past
where
the
plug-in
API
is
a
separate
conversation
right.
How
do
we?
How
do
you?
How
do
you
build
it?
E
There's
a
lot
of
like
thought
leaders
in
that
space,
there's
a
lot
of
prior
art,
but
separating
it
from
the
the
the
the
verticals
that
we're
currently
working
on
the
features
that
we're
currently
working
on
kind
of
puts
it
in
a
place
that
that
that
is
separate
and
I.
Think
it
really
should
be
foundational,
and
so,
in
my
opinion,
it
should
go
along
with
the
features
that
we're
building
in
and
that
plug-in.
Api
is
not
one
and
done
that's
going
to
be
constantly
evolving.
E
It's
constantly
going
to
be
growing,
we're
we're,
hopefully
not
going
to
be
modifying
and
changing
it,
but
it
is
going
to
be
added
to
so
I
think,
like
Thomas,
you
know
at
the
beginning
of
this,
his
his
big
issues
were
Monaco
and
the
visual
operation,
Builder
I,
think
there's
an
understanding
about
Monaco
and
its
complexity
and
how
we
just
you
know
we
need
to
throw
bodies
into
it,
which
is
which
is
great,
get
people
ramped
up
and
and
able
to
contribute
to
the
the
more
frequent
discussions
that
I
hope
we're
going
to
have
about
it.
D
Yeah
I
was
maybe
suggesting:
do
you
think
it
might
be
worth
doing
a
kind
of
meeting
with
you,
Ricky
and
other
people
that
know
Monaco
from
from
Esco
team
to
just
see
you
know
what
you've
been
worked
on,
what
what's
the
current
state
and
maybe
try
to
find
a
path
forward,
because
it
would
be
good
to
kind
of
share
knowledge
as
well
on
that
maybe
have
a
document
like
not
like
a
recap.
Talk.
E
That's
a
great
idea
in
terms
of
in
terms
of
Monaco
in
graphical
I,
want
to
I
want
to
reiterate
again
that
the
work
that
I've
done
is
is
simple
validation
like
they're
I,
really
haven't
done
I'm
just
this
week,
digging
into
like
sort
of
more
complicated,
really
truly
working
with
the
API,
so
I
think
that's
a
great
idea.
I
would
love
to
to
I?
E
Would
love
to
see
I,
don't
know
if
the
Prototype
I've
been
building
is
the
right
test
bet
because
it's
kind
of
messy
it's
kind
of
gross
like
it's
it's
fast
and
quick
and
not
wonderful,
but
if
there
are,
if
anybody
else
wants
to
take
a
stab
taking
graphical
and
putting
Monaco
into
it,
that's
great
I've
been
not
avoiding
the
current
graphical
code
base,
but
I'm
just
focusing
more
on
design
stuff,
that's
just
kind
of
what
I've
been
doing.
E
So
we
know
that
we
we
need
someone
who's
taken
the
current
version
of
graphical
and
try
to
put
Monaco
into
it.
I,
don't
think
that's
happened
yet
I,
don't
think
anyone
has
done
that.
E
That
would
be
great,
that's
I,
think
the
right
path
and
then
once
that's
done
and
we
sort
of
figure
out
what
pain
points
there
are
what
this,
but
the
switch
would
look
like,
then
I
think
it'd
be
great
to
get
other
people
involved
because
right
now,
I,
just
I,
don't
have
enough
I,
don't
think
I
have
enough
to
contribute
to
the
Monaco
discussion.
I
really
don't
like
I
wish.
E
I
did
I
I
wish
I
had
more
to
offer,
but
I
really
don't
think
that
I
do
because
it's
really
just
been
like
fundamentally
getting
it
up
and
running.
I
should
probably
be
better
about
socializing,
a
lot
of
that
work
that
I've
been
doing
but
but
I
haven't.
E
B
E
B
E
Please
I'll
make.
B
A
fork
and
just
focus,
like
you,
said
on
just
a
Monaco,
because
most
of
mine
are
similar,
where
it's
like
mixed
in
with
some
other
experiment,
I'm
running
so
yeah
I,
think
that
would
work
well.
E
B
Right
now
we're
using
the
building
blocks,
but
it's
mostly
all
the
same
like
it's
just
with
like
a
few
components
kind
of
in
between
and
we
use
Monaco
primarily
at
Postman.
So
I'm,
you
know
encouraged
to
make
the
switch
happen.
So
I'll
I'm.
E
All
right,
I'll
make
it
I'll
make
a
note
of
that
here.
Patrick.
Does
that
help
with
the
point
that
you
made
a
little
bit
ago?
Oh.
D
Yeah
definitely
yeah
yeah
I
was
just
trying
to
figure
out
what
would
be
the
kind
of
next
powerful
word
for
this
as
well
so
I
mean
yeah
team
starting
an
experiment
would
be
amazing.
F
We
do
have
a
few
engineers
at
Postman
that
probably
have
some
solid
Monaco
knowledge,
and
so
maybe
we
could
have
you
know
Holden
office
hours
for
graphical
and
Monaco
and
bring
along
some
Engineers,
for
you
know,
answering
questions
and
help.
You
know
just
helping
other
people
here
like
up
there,
their
knowledge
and
capability
on
Monaco.
If
that's
of
Interest
again
I'm,
not
obligating.
Anybody
because
they're
not
here
but
I-
am
willing
to
pursue
it.
If
it's,
if
you
guys
think
it
would
be
useful.
E
Right
I
want
to
I,
see
Ricky's
back
I
want
to
just
quickly
ask
if
Ricky
did
you
hear
what
I
was
saying
about
how
there
hasn't
I,
don't
think
that
there's
been
an
attempt
to
in
the
current
version
of
graphical
replace
code
mirror
with
Monaco
like
I?
Don't
think
anyone
has
is
actually
done.
That
yet,
is
that
correct.
G
C
G
That
would
be
awesome
and
I
would
love
to
help
you
Jim,
yeah,
I,
think
I.
Think
you
you'll
you'll
get
to
make
it
maybe
a
little
bit
simpler.
I
think
this
is.
The
thing
is
I.
Think
the
my
theory
is,
the
SDK
built
from
purpose
for
Monaco
will
be
slightly
simpler
and
have
slightly
less
state
to
manage,
because.
E
The
one
the
one,
the
one
bit
of
Monaco
knowledge
that
I
feel
pretty
confident
in
so
far
is
defeating
of
the
editors
and
I,
also
know
the
the
root
CSS
file,
that's
in
graphical,
pretty
well
and
the
custom
CSS
properties.
So
if
you
run
into
any
issues
with
theming
I,
I'm
I'm
a
great
resource,
that's
about
the
edge
of
my
my
money
to
contribute
that
if
you
have,
if
you
get
stuck
there.
C
E
All
right,
so
that
sounds
like
maybe
we
can
wrap
Monaco
for
now.
I
have
a
load
of
discussion,
a
load
of
thoughts
on
the
visual
query,
Builder
the
visual
operation
Builder
as
I
told
Thomas,
and
this
delay
team
a
couple
of
weeks
ago.
I
think
it's
primarily
a
design
exercise.
A
bunch
of
nerds
sitting
around
writing
code
aren't
going
to
get
that
one
done.
It's
really
a
design
problem
that
we
need
to
that.
E
We
need
to
begin
to
pick
apart
and
uncover
and
I
don't
want
to
take
up
the
next
five
hours.
Barfing
out
my
thoughts
about
the
design
for
the
visual
operation.
Builder.
Does
anybody
have
anything
that
we
just
want
to
make
a
note
of
and
begin
to
tackle
about
the
visual
operation,
Builder
foreign.
B
My
one
little
bit
was
like
following
the
cursor
around
you
asked
in
the
channel
of
like
how
the
users
responded,
and
we
had
a
little
demo
yesterday
and
the
users
didn't
like
it.
So,
but
yes,
there's
a
lot
that
we
can.
I
can
hopefully
like
pass
back
and
forth
on,
like
our
user
testing,
as
we
kind
of
do
things
so
yeah.
E
Are
you,
are
you
doing
any
competitive
analysis
in
that
research?
The
obvious
comparison
is
Apollo
sandbox.
They
handle
it
brilliantly
they're
million
Engineers
they
handle
it.
E
That
interaction
is
correct
as
far
as
I'm
concerned.
I,
don't
I'm,
not
a
fan
of
the
way
that
they
page
the
views
through
the
visual
query.
Builder
I
much
prefer
the
tree-like
structure,
because
especially
for
something
like
graphical,
where
we're
sort
of
targeting
a
range
of
users
right
like
a
lot
of
people's
first
experience
with
graphql
comes
from
graphical
and
I.
Think
that
tree
structure
indicates
a
really
powerful
message.
E
E
Visual
operation,
Builder
View,
is
sort
of
led
by
the
depth
of
the
query
that
you're
trying
to
trying
to
to
get
built
other
than
that
I
think
their
interaction
with
Monaco
is
brilliant,
like
it's
a
really
smooth
it,
it's
it's
it's
it's
great
and
part
of
that
is
the
moving
the
the
cursor
right,
which
is
tracking
active
operations.
It's
tracking
active
fragment
definitions,
it's
tracking,
all
kinds
of
stuff,
so
I,
that's
a
just
I
shouldn't
have
gone
that
deep.
E
Are
you
looking
at
Apollo
sandbox
as
like
as
a
as
an
example
as
a
competitive
as.
B
Our
designers
is
pretty
similar
in
that
like
in
some
ways,
I
kind
of
like
digging
in
just
because
it
can
show
more
of
the
description
of
things.
The
paging,
like
you
call
them
for
Apollo,
but
we're
similar
of
wanted
to
show
the
graph
so
we're
trying.
D
G
G
So
they
can
contribute
towards
something
in
Apollo
studio,
so
they
can
use
something,
that's
open
source
and
contribute
back
towards
the
open
source
Community
there
and
I.
Don't
I,
don't
know
why
or
what
I
can't
remember
exactly
who
it
was.
So,
if
you're
out
there,
whoever
mushrooms
that
reached
out-
and
you
know
and
suggested
that
that's
awesome
and
if
it
never
happened,
it
was
just
a
dream,
then
take
into
consideration.
E
Person
she
works
for
us
yeah.
That
would
be
great
they're
this
as
I
when
I
poke
around
sandbox
is
they've
tokened,
the
editor
correctly,
so
the
default
hat
like
it
it
doesn't.
It
doesn't
know
what
a
field
is.
It
doesn't
know
what
an
argument
is
it
it
it.
It
they've
done
a
really
good
job
there,
if
that,
if,
if
just
that
bit
comes
back
to
us
in
the
open
source
community,
that
would
be
a
really
really
big
help,
but
I'm
sure
there's
a
whole
bunch
of
other
that
they're
doing
inside.
D
E
Free
ship
that
we
would
also
really
really
love
to
have
yeah.
D
D
G
The
parser
itself
is
part
of
the
issue
and
and
like
our
personal
strategy,
currently
requires
full
strength.
That's
parsing
for
certain
things.
Was
it
just
like
certain
certain
things
we
might
not
be
able
to
do,
but
I
think
we
can
still
do
context
tokens
for
autocomplete
and
popover
at
least
yeah,
so
I
think
what
you're
suggesting
John
I
think.
Maybe
it's
down
the
road
but
yeah.
We
could
definitely
adopt
a
token-based
parser
approach
like
a
holiday.
D
Yeah
I
don't
know
what
strategy
we
have
around
the
Explorer
in
general,
so
yeah
need
to
check,
but
to
me
like
it's,
if
we
can
contribute
like
all
the
things
we've
done,
I
think
it
would
be
amazing.
E
Okay,
so
we're
coming
up
on
an
hour
I
think
we
I
think
in
terms
of
the
Monaco
and
the
visual
operation,
building
I
think
we've
had
a
wonderful
conversation,
the
most
productive
working
group
conversation
in
the
last
few
months
because
well
we
just
haven't
been
having
them
every
month.
So
it's
great
to
it's
great
to
see
new
people.
It's
Patrick,
it's
great
to
finally
meet
you
I've,
been
following
a
lot
of
the
conversation
of
Discord
and
underscored
in
the
GitHub
discussion.
Tim
doc
awesome
to
meet
you
Ricky
great,
to
see
ya.
E
Does
anybody
have
since
we're
coming
up
to
an
hour?
Does
anybody
have
anything
else
that
they
want
to
bring
up?
That
I
can
note
on
the
Google
Docs
of
particular
interest.
I
was
I.
Actually
I
have
one
thing
Patrick.
You
were
attempting
to
theme.
You.
D
E
A
E
Love
to
see
I'd
love
to
see
that
theming
surface
change
over
time
without
it
having
to
be
like
a
big
deal.
Unfortunately,
if
it
looks
like
it
could
be
a
minor
breaking
change
at
this
point
right
because
of
the
way
that
the
variables
are
used,
can
you
summarize
your
thoughts
on
your
experience,
attempting
to
theme
graphical
version,
two
and
and
some
of
those
pain
points,
I'd
love
to
just
make
those
notes.
D
Yeah
definitely
so
I
mean.
The
main
issue
was
basically
that
we,
we
have
a
lot
of
CSS
variable,
which
is
fine,
but
there's
also
a
lot
of
colors
that
depend
on
other
colors
without
changing
this
I
think
it's
just
maybe
the
opacity
or
something
like
that.
So
it's
like
depending
the
colors
depending
on
others.
So
if
I
want
to
change
like
a
single
color,
it's
very
difficult
to
do
in
some
places
and
basically
what
I
was
trying
to
do.
E
So
I
can
I
have
a
little
I.
Have
some
thoughts
on
that
so
I'm
gonna
talk
and
not
take
notes,
because
I
can't
do
two
things
at
once.
I
think
it's
important
for
us
to
set
a
boundary
for
theme,
ability
with
graphical
it
could
easily
get
out
of
hand
and
just
unmanageable
over
time.
E
I
think
changing
the
background.
Color
is
a
obviously
something
that
we
that
just
should
be
simple.
Whether
that's
like
you
know
a
prop
called
background.
Color
or
that's
that's
derived
from
some
other
sequence
of
events
is
Up
For,
Debate
I
would
I
would
suggest
that
it
just
the
design
needs
to.
First
of
all,
the
complexity
in
the
layered
contrast
in
that
neutral
scale.
I've
said
this
before
I'm
gonna,
like
put
my
foot
down
firmly
now
and
say
that
it's
it's
not
helping
anything.
E
The
surface
that
exposed
is
very
weird
if
you
go
into
for
those
that
are
interested.
If
you
go
into
the
Prototype
that
I've
been
working
on
I'm
exposing
a
much
it's
not
exposed
yet,
but
it's
a
much
simpler,
color
surface
from
which
to
begin,
there's
three
surface
colors,
there's
four
text
colors
and
then
there's
a
range
of
color
colors
that
are
primarily
meant
to
be
assigned
directly
to
the
type
system
in
graphql
that
Prof
that
propagates
throughout
the
entire
system.
So
I
would
I
think
it's
a
much
easier
surface.
E
It
is
going
to
restrict
the
full
flexibility
of
you
know,
just
being
able
to
like
override
one
specific
color
somewhere
but
I
think
in
terms
of
themeability.
It
offers
a
much
more
like
attractive
package.
I,
don't
know
what
the
surface
exactly
looks
like
on
the
prop
side,
like
on
the
on
the
input
side,
but
I
think
I've
made
a
lot
of
I
have
specifically
attempted
to
make
effort
in
improving
that
possibility
going
forward.
It's
not
applied
at
all
in
current
graphical.
It
doesn't
live
there,
but
I
think
we
can.
E
We
can
I
would
expect
that
that
changes
over
time
and
that
that
theming
part
of
it,
because
I
don't
know
that
there
are
a
lot
of
people
that
are
so
many
people
that
use
graphical
are
just
happy
that
there's
a
dark
mode
that
they're
not
really
like
getting
involved
deeply
with
customization.
E
The
the
deepest
customization
that
I've
seen
is
graph
base
graph
base
has
like
pretty
radically
redesigned
like
not
not
radical
radical,
but
radical
enough
has
redesigned
it
so
clearly,
like
the
existing
surface
works
for
a
lot
of
folks,
they
seem
to
have
have
they
seem
to
be
very
happy
with
it.
But
I
would
like
to
see
that
change
over
time.
I'm,
not
sure
where,
on
the
priority
list
it
you
know
where
it
lies.
Yeah
I.
D
Mean
what'd
you
just
described
like
changing
some
base.
Colors
would
be
I
think
it
would
be
great.
That's
that's
what
I
wanted
to
do.
Basically,
at
the
end,
I
just
wanted
to
change
like
some
colors
and
not
nothing.
Much
like
and
I.
Don't
know
we
still
have
like
the
ability
to.
You
know:
customize
CSS.
If
we
want
to
so
like
we
can,
have
you
know
our
public
apis,
the
colors
and
then,
if
someone
wants
to
change
everything
else,
they
can.
G
G
So
it's
a
user
supplies.
A
settings
configuration
maybe
like
something
like
a
graphical
config
type
configuration.
Then
the
fetcher
is
automatically
generated
for
them,
and
then
we
have
in
in
State
this
concept
of
environments
or
projects
or
something
like
that
and
you
can
choose
which
one
to
execute
operations
against
and
obviously
for
the
schema
to
validate
against
and
whatnot.
G
And
then
the
idea
is
also
that
have
like
a
plug-in
that
would
be
like
a
network
configuration
management
tab
where
you
can
manage
say
like
Global
configurations
and
per
project
or
per
environment,
so
to
speak
configurations,
and
this
is
based
on
a
lot
of
different
conversations
and
feature
requests
over
time.
I'm
going
to
go
back
and
Consolidated
a
list
of
all
of
them
that
that
it's
referencing
and
it
doesn't
have
to
all
happen
at
once.
G
I
think
the
first
part
would
happen
and
then
the
network
tab
can
happen
later,
but
but
the
idea
of
making
fetcher
potentially
optional
and
allowing
the
user
Supply
some
kind
of
declarative
configuration
to
generate
a
filter
is
like
the
kind
of
the
first
proposal
to
to
mold
I.
Guess.
E
Is
is
I
think
this
is
a
great
idea.
Is
this
partially
a
reaction
to
the
plethora
of
factory
related
issues
that
we
got
in
the
Repository
partially.
G
E
E
You
go
to
you
go
to
the
repo
you
file,
an
issue,
somebody
fixes
it
within
24
hours
or
you
just
didn't,
do
something
right,
that's
a
pain
in
the
ass
because
it's
generating
issues,
but
it's
also
a
relatively
simple
fix
without
we've
talked
about
this
before
Ricky,
but
without
like
a
sort
of
better
documentation,
presentation
for
graphical
writ
large,
adding
complexity
to
the
fetcher
without
a
better
documentation
view
overall
is
going
to
make
the
Beauty
and
the
Simplicity
of
the
current
situation
potentially
I.
Think.
E
G
G
G
So
it's
a
it's
a
very
common
use
case
and
it
would
make
it
so
that,
like
any
graphical,
server
could
easily
be
full
feature
to
that
regard
by
just
saying:
okay,
you
know
we
have
graphical
and
you
can
configure
it
for
whatever
Network
tabs
you
have,
and
it
also
let
us
kind
of
be
a
reference
implementation
for
the
HTTP
specs,
because
then
we
can
give
them
the
full
options
that
are
available
in
the
http
spec.
As
user
settings.
E
G
Think
it
would
be
like
a
declarative.
Config
object
would
be
a
better
reference
point
than
like
great
graphical
Adventure,
which
is
like
a
good
reference
implementation.
If
you
want
her
to
look
and
how
to
read
it,
it's
a
little
bit
obscure
as
it's
evolved,
especially
with
multi-part
incremental
delivery.
It's
hard
for
people
to
wrap
their
heads
around
the
spec
implementation
from
there.
So
and
people
are
using
this
as
a
point
of
it's.
Why
we
don't?
G
We
didn't
pick
one
other
existing
client
to
do
that,
because
it
needed
to
be
a
reference
and
kind
of
be
unopinionated,
and
so
that
we
didn't
say
we
favored
this
client
over
another,
but
then
yeah.
So
that
means
we
also
have
to
maintain
a
full
spec
ific,
just
just
food
for
thought,
though
I
mean
yeah
I
agree.
The
effective
crop
is
magically
beautifully,
powerfully
easy
to
work
with,
but
there's
examples
of
where,
like
a
declarative
configure,
would
be
nice,
for
example.
G
So,
like,
let's
say
you
change
a
header
value
that
you
want
for
all
your
default
operations
and
endpoint
doesn't
change,
and
you
don't
need
to
because
you
know
the
endpoint
is
the
same
as
before.
All
these
other
values
change.
So
it
gives
us
a
little
bit
more
flexibility
as
those
values,
change,
yeah.
E
Yeah
but
I
do
that
other
complexity,
issues
yep
all
right,
okay,
so
I,
didn't
I,
didn't
take
any
notes
there,
because
I
was
trying
to
listen
and
not
enough
right,
but
I.
F
E
F
Why
I
was
trying
to
write
John
is
I
was
trying
to
jump
in,
for
you.
I
also
wanted
to
correct
something
on
here,
but
I
don't
seem
to
be
able
to
edit.
F
F
E
If
you
send
me
in
send
me
a
note,
I
can
make
that
change
real
quickly.
Thomas
owns
the
actually
maybe
I
own.
The
document
now
too.
F
Foreign
yeah
so
either
I
misunderstood
what
Patrick
said
about
plugins
or
whoever
took
these
notes
did
so
I.
What
I
was
agreeing
with
Patrick
on
or
I
thought
I
was.
Was
that
going
to
Monaco
as
a
single
editor
and
developing
plugins
based
on
Monaco,
as
the
editor
was?
What
the
was
the
position
that
I
was
trying
to
support,
not
an
abstraction
over
whatever
editor.
E
D
E
D
Didn't
mention
both
like
I
was
saying
like
it
would
be.
You
know
quite
a
bit
of
work
to
have
an
obstruction,
and
so
we
you
know
we
we
should
choose.
Either
options
are
like
you
know,
one
allows
to
use
both
editors,
so
people
can
switch,
but
the
other
one
is
less
work
for
us
and
I.
Guess
it's
even
more
powerful
because
you
know
like
people
can
tap
into
Monaco.
If
we
give
them
the
ability
to
do
that.
Foreign.
E
Okay,
so
we'll
let
you
fix
that
we're
over.
Does
anybody
else
have
anything
that
that
they
want
to
that?
They
want
to
bring
up
that
we
can't
handle
over
Discord.
E
Three
two
one:
okay,
well
I,
want
to
say
again
that
it's
a
real
pleasure
meeting,
Patrick
Tim
and
Doc
a
pleasure,
seeing
you
again
Ricky
hope
you're
doing
well
over
there
in
Germany,
let's
shut
it
down
for
now,
I'll
see
you
all
on
Discord,
I'm,
I'm,
I'm
I've
spent
a
lot
of
the
last
few
months,
working
on
this
and
I'm
I'm
I'm
enthused,
and
excited
that
there's
more
folks
at
these
meetings,
I
think
it's
great
I
think
we
need
to
do
a
better
effort
to
making
sure
that
we're
having
this
meeting
every
month
and
everybody
have
a
nice
day.