►
From YouTube: JupyterLab Dev Meeting, October 7, 2016
Description
Meeting of the JupyterLab development team, October 7, 2016.
Meeting Notes: https://jupyter.hackpad.com/JupyterLab-Weekly-Meetings-UUJ3gIQ3iBS
A
All
right,
good
morning,
internet,
it's
Friday,
October
7th,
and
this
is
the
Jupiter
lab
weekly
meeting
today,
we'll
have
a
short
meeting.
We
have
a
bunch
of
our
team
out
in
New
York
working
around
strata
and
some
other
development
work
that
we
have
going
on
there
with
Bloomberg
at
Microsoft.
It
sounds
like
today,
Ian
might
have
a
few
questions
for
the
Jupiter
lab
team
or
an
update
on
the
work
that
he's
been
doing,
feel
free
to
ever-so-gently.
B
B
Between
them,
through
the
through
the
google
api's,
but
one
of
the
questions
that
I've
been
having
it
right
now,
I've
just
sort
of
been
hacking.
Things
in
you
know
as
necessary,
so
there
isn't
really
a
whole
lot
of
structure
and
where
I've
been
making
changes.
So
one
of
the
questions
I
have
for
the
people
who
are
more
familiar
with
the
architecture
of
Jupiter
lab
is
how
do
we
see
this
fitting
into
the
overall
structure?
Is
this
the
type
of
thing
which
is
better
off
as
a
extension?
B
B
D
Conceptually
an
interesting
idea
to
see
if
it's,
if
it's
possible,
to
structure
it
this
way
because
am
I
in
my
mind,
it
would
be
the
cleanest
way
to
go
about.
It
is
that
if
we
could
have
an
extension-
or
you
know
the
plug-in
like
it
like
any
other
thing
in
Jupiter
lab
that
provides
an
abstract,
API
or
real-time
collaboration.
That
could
then
be
loaded,
then
be
implemented
by
various
extensions,
because
we
can't
always
use
the
Google
real-time
API,
like
that,
won't
work
right
now.
D
People
in
certain
situations,
so
I
could
come
up
with
a
sufficiently
abstract
API,
which
we
can
define
three
interfaces
and
then
have
as
an
extension,
that's
available
like
some
default
implementation.
Let's
say
it's
google's
or
whatever,
and
then
we
can
go
back
and
update
our
document
models
for,
like
the
text
editor
and
the
notebook
and
that
sort
of
thing
to
then
consume
these
api's
as
necessary.
Maybe
we
have
like
a
real-time
version
of
the
notebook
that,
instead
of
having
a
regular
notebook
model,
has
like
a
real
time,
no
football.
D
That
depends
on
these
implementations
of
this
of
that
real-time
API
interface,
and
so,
if
we
can
get
that
to
work
and
if
there's
a
way
to
sufficiently
abstract
over
Google's,
real-time
API
is
such
that
they
can
be
up
such
that
it
can
be
implemented
by
other
real-time
API
systems
than
I.
Think
that
would
be
a
way
to
go
about
it
and
then
once
we
have
that,
then
we
can.
Then
we
can
see
about
how
we
then
the
best
way
to
incorporate
that
into
the
text.
D
So
maybe
we
have
like
a
book
widget
and
a
real-time
notebook
widget
that
hooks
up
to
these
api's
and
then
a
text
editor
and
a
real-time
text
out
of
that
sort
of
thing,
so
that
that,
like
on
the
surface
on
some,
like
that's
telling
me
that
it
should
be
structured
at
a
high
level.
Of
course,
any
more
complex.
Once
you
get
into
the
details,
that's
that's
kind
of
you.
I
would
take
if
I
was
starting
out
on
something
like
this
to.
B
C
D
Local
and
I
want
two
more
for
this
into
a
real-time
editor,
or
something
like
that.
So
we
just
swap
out
the
widget
under
the
hood
and
glowed
look
basically
load.
What
was
in
the
old
text?
Editor
real-time
text
there.
So
there
are
there
ways
around
that
and
would
want
me
to
use
or
which
approach
we
choose
is
really
in
a
depend
on.
B
D
They
can
be
handled
much
more
efficiently
and
cleanly
if
the
widget
goes
and
dealing
with
the
real-time
model
and
abstracting
that
away
that
sort
of
information
away
to
where
the
document
model
doesn't
know,
whether
it's
real
time
or
whether
it's
not
real
time
can
be
difficult
unless
aying
it's
impossible,
but
it
can
be
difficult
and
we
won't
know
which
one
which
way
we
need
to
go
until
we
actually
get
in
there
and
start
opening.
But
I
do
think
that
was
the
right
advice.
D
B
A
C
E
A
E
But
about
the
same
just
trying
to
keep
up
with
outstanding
issues
with
a
point.
Nine
mile
story
released
point
five
this
morning,
but
the
remaining
major
hurdle
feature
wise
is
getting
lab
exceptions
to
work
across
different
versions
of
Jupiter
lab
and
phosphor
and
rectifying
all
that.
So
we're
working
on
that
internally.
A
solution
of
that
waiting
to
talk
to
jason
about
that,
but
he's
been
meeting
with
others
this
week,
including
today,
so
hopefully
we'll
make
some
progress
next
week
on
that
front.
What's
it
cool.