►
From YouTube: JupyterLab Team Meeting - September 7, 2022
Description
A meeting to share and discuss features, ideas, issues, and pull requests in JupyterLab and other Jupyter frontends. This meeting is open to anyone and everyone.
Join future calls via the Jupyter community calendar: https://docs.jupyter.org/en/latest/community/content-community.html#jupyter-community-meetings
Notes for upcoming meetings can be found on the agenda: https://hackmd.io/Y7fBMQPSQ1C08SDGI-fwtg
Past notes can be found on the JupyterLab team compass: https://github.com/jupyterlab/team-compass/issues?q=is%3Aissue+label%3A%22Dev+Meeting+Minutes%22
A
Hi
everyone
welcome
to
the
September
7th
Jupiter
lab
weekly
call.
Today
we
have
14
people
on
the
call.
That's
that's
been
like
and
we
have
what
appears
to
be
a
sparse
agenda
as
well.
So
why
don't
we
get
started?
We
have
at
the
top
of
the
agenda.
Frederick
has
a
bunch
of
things
that
he
wants
to
announce,
but
I
don't
believe
he's
on
the
call.
A
Let's
see.
The
first
point
is
that
Jupiter
lab
3.4.6
and
Alpha
28
were
published,
and
then
there
is
some
feedback
on
your
side
by
2022,
where
he
worked
on
a
poster
session
for
lab
and
notebook
which
you
might
be
curious
about.
Let's
link
there
and
also
Jupiter
light
and
other
talks
that
he's
got
some
information
on
there
that
you
might
want
to
follow.
A
Apparently,
the
czi
Grant
application
for
the
notebook
7
transition
was
not
accepted.
Oh
man,
the
page
just
moved
out
from
under
me
thanks.
Whoever
did
that
and.
A
B
A
Cool.
Thank
you.
That's
good
to
know
that
lumino,
sorry,
that
4.0.0
Alpha
28
was
the
basis
of
trying
to
update
Jupiter
notebook,
but
I
think
I'll
talk
about
that
when
I
talk
about
Louboutin
yeah,
any
other
questions
or
comments,
or
should
you
move
on.
B
C
It
might
just
be
me
so
at
quantite
we
have
an
intern
from
July
21st
to
October
21st
named
cool
soon,
who
is
going
to
be
working
on
some
Jupiter
lab
accessibility
issues
and
something
that
we
were
recently
taking?
A
look
at
was
the
cell
toolbar
and
specifically
when
the
user
interface
is
like
zoomed
up
really
high
and
anyway
we
we
did
some
looking
through
GitHub,
maybe
not
as
extensively
as
we
could,
but
we
thought
it
might
just
be
good
use
of
this
time.
C
If,
since
Jason
is
on
the
call,
if
he
could
maybe
just
quickly
explain,
there's
just
a
section
of
CSS
that
we're
not
entirely
sure
why
it's
set
up
the
way
it
is
and
I
don't
know.
If
that,
if
we
could
do
that.
D
D
I'll
tell
you
what
let
me
take
a
look
at
this
because
I
didn't
realize
you
were
tagging
me
nine
times
out
of
ten,
it's
Mr
grout,
who
is
being
referred
to
so
I
will
can
I
should
I
just
respond
in
the
in
the
context
here
or
is
there
an
email
address?
I
can
contact
you
about
yeah.
C
D
On
on
a
group,
this
big
on
a
call,
this
recorded
I,
don't
know
if
that's
the
best
forum
for
this,
so
I
can
kind
of
walk
through
it
and
give
a
basic
summary
of
it
and
context
in
here
and
I'll
include
my
email
address.
If
you
want
to
like
drop
me,
a
line
about
it,
okay,.
C
A
All
right
cool.
Thank
you
before
I
talk
about
the
things
that
I
added
to
the
agenda.
I
will
exhort
you
again.
If
there's
something
you'd
like
to
talk
about,
please
add
it
to
the
agenda,
but
I
have
three
unrelated
things.
To
talk
about.
A
A
If
we
don't
like
it,
that's
fine,
but
it
seems
like
low-hanging
fruit,
because
I
think
everyone
on
the
council
has
a
GitHub
account
everyone's
already
on
the
team,
the
relevant
team
I
wonder
if
there's
actually
some
some
auditing
of
the
access
to
the
GitHub
org
that
we
should
do
and
whether
it
reflects
what
the
actual
permissioning
structure
of
the
different
repos
ought
to
be.
I,
don't
know
for
sure,
but
I
acted
as
though
the
Jupiter
lab
Council
team
is
the
entity
that
ought
to
have
permission
to
this
repo
and
I.
A
Didn't
really
I
didn't
find
a
good
way
of
figuring
out
if
I've
made
a
mistake
with
that,
but
we
can
also
discover
that
too
I
didn't
put
a
license
on
that
repo,
because
I
expected
to
have
no
code
in
it
and
if
it
did
have
stuff
in
it.
Presumably
we
actually
wouldn't
want
it
to
be
liberally
licensed
and
trivial
to
Fork.
We
actually
would
want
it
to
remain
private,
presumably,
but
rest
assured
there's
no
content
in
there
yeah,
so
that
was
that
I
also
to
the
team
Compass.
A
There's
a
link
here,
I
pinned
an
issue
for
hosting
this
call
and
I
put
in
all
of
the
dates
for
this
call,
basically
every
Wednesday
until
the
end
of
the
year.
If
you
would
like
to
please
put
your
name
in
there
and
if
you
have
any
questions
about
the
mechanics
of
it,
I'm
happy
to
talk
through
it
with
you,
several
other
people
have
hosted
these
calls.
We've
had
Fred
and
Isabella
and
Alex
Tim,
George,
Steve,
Jason
I.
Believe
you
posted
some
so
yeah.
A
If
you
have
any
questions
about
the
mechanics
of
it
or
anything
else
or
if
you
have
an
inclination
to
do
it,
please
add
your
name
to
that
list.
I
am
happy
to
be
the
host
of
Last
Resort
like
if
there's
no
name
there
I'll.
Do
it.
That's
fine,
but
it's
more
that
I
think
maybe
other
people
would
like
to
and
also
you
know.
Sometimes
you
have
to
do
stuff
on
Wednesdays.
A
Okay,
so
my
third
bullet
point
is
about
the
lumino
2
migration
and
there
was
a
large
pull
request
open
to
my
great
Jupiter
lab
Force
code
base
to
luminol2
and
that's
been
merged.
It
touched
a
lot
of
files
and
probably
caused
every
open
PR
to
require
a
rebase.
A
I
also
had
to
rebase
it
a
lot
of
times
so
foreign
did
endure
some
of
the
pain
I'm
inflicting
on
others,
but
it's
definitely
disproportionate
because
lots
of
things
are
gonna
have
to
change.
But
if
you
look
at.
B
A
It's
primarily
to
do
with
using
native
iterators,
which,
frankly,
not
that
many
people
were
relying
on
the
lumino
things
unless
they
were
following
the
pattern
from
a
super
class
that
was
already
exposing
an
iterator
like,
for
example,
in
the
Jupiter
notebook
for
Shell.
The
shell
lets
you
iterate
through
its
widgets.
That
kind
of
thing,
and
also.
A
If
you
were
using
the
old
P,
Styles,
P,
Dash,
mod,
Dash,
disabled
or
stuff
like
that,
and
then
we
used
that
as
the
basis
of
the
alpha
28,
which
Fred
length
above
and
then
with
both
of
those
published,
we're
trying
to
Port
notebook
7
to
use
lumino2
and
this
version
of
lab.
But
there
was
a
bug
in
lumino
2,
which
meant
we
have
to
go
back.
We
released
lumino
2,
which
we
did
yesterday
and
there's
an
open
PR
that
I
linked
for
bumping
that
version
in
Jupiter
lab.
A
So
if
anyone
has
the
time
and
inclination,
please
merge
that
and
or
publishing
release
and
those
two
things
being
out
will
mean
that
notebook
7's
code
base
can
be
migrated
over
to
use
luminal
2.
notebook.
7's
transition
was
actually
really
fairly
trivial.
It's
just
almost
all
package,
Json
stuff,
there's
a
few
uses
of
to
array
which
is
deprecated
but
still
exists,
and
there
were
there
was
one
place
where
it
exported
an
I
iterator
that
shell,
that
widgets
thing
that
I
mentioned
earlier.
A
So
it's
actually
given
me
some
Solace
that
extension
authors
aren't
going
to
really
be
too
inconvenienced
by
this,
because
all
of
notebook
was
just
a
few
hundred
lines
and
almost
all
that
was
packaged.
Json
updates.
A
Okay,
there
ends
all
of
my
updates
any
questions
or
comments
before
I
move
on.
D
For
for
extension,
authors,
do
you
don't
think
it's
likely
that
they
can
have
an
or
dependency,
so
you
can
say
Lumina,
one
or
two.
A
D
E
When,
when
you
compile
extension,
it
fixes
the
version
of
lumino
and
the
internal
Jupiter
packages,
so
I
think
you
should
be
okay,
it'll
substitute
in
the
actual
core
Jupiter
lab
versions.
For
those.
So
I
think
you
should
be
okay,
if
you
put
either
Sims
in
or
or
don't
use,
parts
that
have
changed
between
the
two
versions.
A
A
The
reason
we
went
with
es2018
instead
of
2017
like
lab,
was
doing
was
because
we
released
the
version
of
poll.
That's
an
async
iterator
and
the
async
iterator
is
not
recognized
without
es2018,
and
so
Jupiter
lab
now
I
put
in
a
PR
to
change
it
to
es2018,
as
no
wait
did
I
do
that.
Yet
if
I
didn't
that's
the
next
step,
but
it
shouldn't
really
make
a
difference.
A
I
think
2017
to
2018
has
minimal
updates,
but
the
bigger
difference
is
the
output
code
from
lumino
is
now
basically
es
next
right.
So
if
you
were
using
it
in
an
older
browser,
you're
probably
going
to
continue
to
use
luminal
one
for
a
while
or
indefinitely
rather
luminal.
One
is
fine
right.
A
D
Yeah
so
I
hate
to
be
digging
up
the
past,
since
everybody
is
moving
on
to
new
and
exciting
things.
But
I
just
had
some
questions
about
the
tree
Acts,
so
I
I
was
trying
to
run
the
Jupiter
lab
Benchmark
thing
again,
some
of
the
3x
branches
and
it
just
failed
right.
The
question
is
I.
Don't
remember
when
was
what
what
is
the
oldest
version
of
Jupiter
lab
or
the
benchmarking
is
supposed
to
work
for,
because
the
background
was
that
I
recently
tried
to
upgrade
from
three
zero
X
I
think
it's
17
or
18.
D
That
is
the
latest
one
there
right
onto
the
latest
on
the
3x
Branch,
the
three
four
four
or
whatever
it
is,
and
the
performance
for
large
notebooks.
If
you
have
a
lot
of
large
notebooks
open
this
drop
quite
significantly
right,
which
was
a
little
bit
surprising
to
me.
Given
that
I
think
most
of
the
things
that
have
touched
there
are
things
that
are
supposed
to
improve
it
right.
D
A
D
D
D
The
more
data
you
have
I
could
try
to
bisect
it
and
figure
out.
You
know
so
if
this
was
a
specific
commit
or
like
a
version
release,
whether
it's
a
chrome
list
that
has
triggered
this
anything
to
help
kind
of
figure
out,
the
cause
should
be
giveful
but
I
I
have
I,
have
tested
this
with
the
same
version
of
Chrome
with
against
triox
versus
3x
latest,
and
the
browser
didn't
affect
that.
D
But,
of
course
there
might
be
an
additional
issue
from
browser
versions.
Well,
so
yeah.
If
anybody
has
any
thing
that
can
help
me
suggest,
which
versions
to
look
at
to
help
dissect
it,
it
would
probably
go
quicker
because
my
notebooks
for
for
my
environment,
where
I'm
able
to
reproduce
this,
isn't
a
easy
tool
to
change
the
version
on
the
rebuild
so
far.
So.
A
A
Yeah,
that
is
true,
cool,
okay,
so
last
call
for
people
adding
stuff
to
the
agenda.
Otherwise,
we'll
move
on
to
additional
discussion,
which
I
see,
has
an
item
in
it
now,
which
is
great
but
yeah.
Is
there
anything
you'd
like
to
announce
any
PR
you're
working
on
you
want
to
talk
about
Isabella.
B
A
I
think
the
word
scheduled
there
implies
we're
going
to
end
early
and
I.
Think
that
might
be
true.
Okay.
B
A
So
why
don't
we
move
on?
Oh
actually,
you
know
what
now's
a
good
time
to
do.
One
final
reminder:
we
picked
the
15th,
which
is
actually
eight
days
from
today
as
the
deadline
for
making
a
nomination
of
someone
who's
in
the
Jupiter
lab
Council
to
be
our
software
steering
Council
representative.
So
that
means
that
if
you
think
there's
someone
who's
not
currently
on
the
Jupiter
lab
Council,
you
can
still
get
them
on
there
in
time
to
nominate
them.
A
Now,
nothing
stops
you
from
making
nominations
two
weeks
from
now,
that's
cool
too,
but
the
sorry
nominations
for
the
Jupiter
lab
Council
right.
But
something
does
stop
you
for
nominations
to
the
SSC,
which
is
we
just
won't
have
enough
time
to
vote.
If
we
wait
much
longer,
we
could
push
it
back,
maybe
one
week,
but
that's
about
it.
So
this
is
an
exhortation.
A
If
there's
someone
you
either
want
to
nominate
for
the
Jupiter
lab
Council
or
if
there's
a
member
of
the
Jupiter
lab
Council
you'd
like
to
nominate
to
run
for
the
SSC
for
that
ladder,
just
double
check
with
them
and
make
sure
they're
willing
to
accept
it
before
you
nominate
them
and
yeah
Fred
made
a
a
post
about
this
in
the
mailing
list.
So
please
submit
your
nomination.
There
I
think!
That's
it
is
that
everything
everyone
needs
to
know
about
this
Jason
or
Jason
cool
all
right.
F
This
was
this
was
a
topic
of
discussion
in
the
Jupiter
widgets
meeting
the
the
topic.
I
need
to
do
a
proper
write-up,
but
Jason
keeps
prodding
me
to
get
something
going.
F
It's
basically
how
to
do
Rich
outputs-
and
this
is
basically
JavaScript
outputs
that
can
do
things
like
open
com
channels
in
a
portable
way.
So
it
works
across
multiple
front
ends
and
does
not
require
extensions
to
be
installed.
F
I've
been
sort
of
like
you
know,
championing
this
for
a
while,
from
the
collab
perspective,
just
a
way
to
make
Rich
outputs
without
extensions,
but
would
really
like
a
proposal
that
would
work
everywhere
across
Jupiter
lab
across
any
other
like
front
ends
and
just
sort
of
I.
Don't
know,
I
guess,
there's
a
little
bit
more
interest
in
it.
It's
not
quite
clear
what
the
Forum
should
be
for
basically
deciding
what
this
is.
I
have
an
initial
prototype.
I
did
a
couple
years
ago.
F
Actually,
at
this
point,
but
I
don't
have
the
sort
of
ability
to
fully
maintain
like
the
Jupiter
lab
extension
in
order
to
fully
support
it
in
in
like
collab,
we
would
have,
we
would
sort
of
want.
We
we
like
to
only
expose
apis
which
are
sort
of
fully
stable,
fully
signed
off,
and
so
we
sort
of
want
before
we
roll
out
like
our
implementation
of
this,
would
want
broader
sort
of
support
from
the
community
to
some
degree.
F
This
is
a
little
bit
of
overlap
with
like
NB
format,
because
this
is
trying
to
do
a
I'd
say
a
bit
of
a
specification
about
how,
like
these
rich
outputs
should
behave
across
all
front
ends.
But
it's
also
I
think
the
this
Jupiter
lab
forum
is
a
little
bit
as
the
people
that
would
be
intended
for
it
curious
about
thoughts
or
any
other.
Did
you
have
anything
to
add
Jason.
E
Sure
yeah,
the
way
the
way
I
thought
about
it
after
you
presented
yesterday
in
the
widgets
meeting,
is
what
you're
proposing
is
a
new
mime
type
that
is
a
javascript-based
mime
type,
but
this
mime
type
when
it's
rendered
has
a
guarantee
of
a
of
an
API
available
to
it
for
Notebook
operations
or
cell
operations
or
being
able
to
connect
to
the
kernel
Etc.
So
the
way
we
sort
of
say,
we
guarantee
that
the
environment
provides
this
particular
API,
as
we
say
for
this
particular
mime
type.
E
That's
cross
front,
end
so
available
in
collab,
databricks,
Jupiter
lab
Jupiter,
notebook,
collab,
I
already
say
collab,
you
know,
whatever
else
other
front
end
is
going
to
support
this
mime
type
and
and
that's
the
question:
what
would
a
minimal
might
would
a
minimal
API
available
to
the
JavaScript
in
this
particular
mime
type,
look
like
in
order
to
give
some
extra
functionality
and
this
sort
of
recaptures
some
of
the
Wild
West
crazy.
But
awesome
exploration
being
able
to
do
cool
things
without
writing.
E
A
lot
of
you
know
npm
packages,
and
things
like
this-
that
we
had
in
the
classic
notebook
where,
where
the
python
code
in
the
kernel
could
send
JavaScript
to
the
front
end
and
do
like
really
cool
stuff
with
the
notebook,
this
kind
of
captures
some
of
that
by
providing
an
API,
that's
a
specific,
but
generic
API
from.
F
The
API
design
perspective
Co-op
has
had
sort
of
a
stable
API.
That's
a
very,
very
Bare,
Bones
API
doesn't
require
any
like
external
libraries.
Anything
like
that,
just
to
keep
it
very
simple
and
the
goal
is,
is
that
it's
almost
its
version
is
basically
like
the
browser
in
that
you
can
check
if
an
API
is
available
and
then,
if
it's
available
it
should
just
work
and
the
intention
there
is
to
really
avoid
versioning
issues
that
you
can.
Just
you
know,
use
this
API.
If
it's
available,
then
you
can
use
it.
E
And
I
think
it
connects
to
the
larger
scope
of
where
you
were
saying,
there's
a
connection
to
NB
format.
You
know:
we've,
we
have
not
defined
any
mime
types
really
from
mind.
Bundles
in
the
notebook
format.
I
think
there's
an
implicit
assumption.
That
text
plane
is
an
available
mime
type
that
is
rendered
as
plain
text
and
whatever
the
front
end.
E
It
is
but
there's
no
other
specification
for
other
standardized
mime
types
that
we
encourage
front-ends
to
support,
and
so
whether
or
not
we
want
to
go
down
that
route
of
you
know
having
an
official
list
of
mine
types
that
we
you
know
have
as
officially
supported
things
or
that
we
encourage
front-ends
to
implement
or
something
like
that.
I
guess.
That's
a
separate
question,
but
but
I
think
your
prototype
is
very
interesting,
because
your
prototype
essentially
makes
a
renderer
for
a
specific
mime
type
for
a
custom
mime
type
that
has
this
API.
B
It
allows
you
to
or
will
allow
you
to
request
at
a
specific
part
of
say
data
frame
and
you
can
imaginate
and
load
the
data
nicely.
B
That
was
discussed
I
think
four
years
ago
before
1.0
release
and
I
recently
bumped
into
that
issue,
and
for
that
that
was
resolved
quite
a
few
of
the
problems
that
renderers
have.
A
A
So
it's
like
the
pagination
queries
all
follow
a
standard
that
matches
that
mind
type
and
there
might
be
like
a
websocket
version
as
well
for
like
a
different
kind
of
stream,
but
that
might
be
basically
both
like
conventional
decisions
made
that
are
tied
to
the
Mind
type
and
completely
agnostic
about
your
implementation
and
agnostic
about,
like
you,
don't
have
to
give
that
much
metadata.
A
F
So
in
the
in
collabs
use
at
least
for
this
and
I
think
which
is
a
fairly
common,
we
see
it
for
I.
Think
some
of
the
cases
that's
come
up
is
just
plotly
bokeh,
like
Altair
being
able
to
create
interactive
Graphics
and
really
because
this
is
trying
to
be
a
long-term,
stable,
API
I'm,
really
trying
to
slim
it
down
to
the
absolute
like
bare
minimum
of
what
needs
to
be
done
for
some
things.
F
Like
you
know,
streaming
You
could
argue
that
it
could
just
be
built
on
top
of
comms,
and
maybe
comms
is
like
the
lowest
primitive
that
we
could,
that
we
would
support
and
I
think
that's.
One
of
the
challenges
here
is
coming
up
with
the
the
sort
of
like
Bare
Bones,
minimal
API
that
can
be
sort
of
useful
and
that
can
be
supported.
Reliably
broadly
across
all
front
ends,
is
sort
of
a
goal.
D
C
D
Was
something
that
was
added
I
think
this?
The
spec
was
open
for
it,
but
there
were
certain
packages
that
didn't
Implement
support
for
it
or
something
like
this
I,
don't
remember
what
it
was,
but
so
the
at
some
point
there
was
changes
to
the
API
right.
So
for
that
minimal
API
you,
you
would
be,
of
course,
completely
unable
to
make
any
changes
like
that.
F
Yeah
I
mean
how
to
the
I
think.
The
question
is
how
to
expose
the
features
so
that
you
can
detect
whether
or
not
the
client
supports
it,
and
one
of
those
may
be
like
send
with
buffers
exposing
a
method
there
that
you
can
check.
If
the
client
actually
supports
that
send
with
buffers
to
try
to
add
mechanisms
to
gracefully
add
those.
The
API
needs
to
be
able
to
support
like
adding
additional
functionality,
but
it
needs
to
be
sort
of
graceful
and
allow
clients
to
to
know
whether
or
not
an
API
is
supported.
F
F
I
mean
so
some
word,
MIME
type,
I
think
that
the
goal
was
really
to
avoid
semantic,
versioning
and
I
think
use
a
more
like
browser
type
API,
where
this
is
as
minimal
as
possible
and
that
you
know
old,
old
content
against.
Like
you
know,
version
there
shouldn't
be
version,
one
over
version,
2.0
breaking
changes,
Etc
I
think
we
can
just
support
like
a
minimal
API
with
graceful
additions.
F
You
know
that
I've
I've
linked
elsewhere
to
the
the
API
that
the
collab
uses.
That's
something
that
we've
had
stable
for
a
very
long
period
of
time
and
we've
been
very
sort
of
careful
about
what
we
add
there
and
I
think
that
model
can
work
for
multiple
front
ends.
F
A
A
It
really
does
need
to
be
published
somewhere
with
some
assurances
that
this
is
still
moving,
that
this
is
going
to
be
long,
lasting
and
not
just
the
clever
thing
that
we
shipped
with
Jupiter
lab
so
I
think
one
thing
that
I
will
do
as
a
follow-on
to
this
call
is
send
a
message
to
the
people
that
I
know
who
volunteered
to
be
on
that
sub
project
and
say:
hey
I
want
to
do
some
work,
and
by
next
week
maybe
we
can
arrange
follow-on
conversations
and
figure
out
how
to
not
wait.
E
Yes,
I
am
it's
kind
of
interesting,
though,
that
in
Jupiter
a
lot
of
times
the
standards
follow
the
implementation.
E
Sometimes
the
standards
precede
the
implementation,
but
are
informed
by
prototypes,
and
so
in
this
case,
if
you're
trying
to
establish
an
API
that
is
cross-platform
cross
front
end,
you
know
IPython
would
be
a
good
place
for
it.
As
in
that's
the
kernel
back
end,
maybe
that
would
have
at
least
an
initial
implementation.
E
Jupiter
lab
would
be
a
good
place
for
it
to
to
rough
out
an
idea,
maybe
inspired
by
the
existing
API.
That's
in
collab,
but
both
of
those
I
think
would
inform
a
standard
discussion.
E
So,
while
I
think
standards
could
take
it
up,
I
think
being
real
informed
by
work,
it
doesn't
do
any
good
to
publish
a
standard
which
no
one's
going
to
implement.
It.
I
think
the
web
has
shown
us
that
that's
a
pathway
to
nowhere.
So
so,
if
I
was
on
the
standards,
putting
my
standards
committee
hat
on
I
would
say:
where's
the
implementation
and
you
know
are
Jupiter-
is
Jupiter
lab
slash,
Jupiter
notebook
committing
to
maintain
it
like
do
they
want
to
support
this
as
a
standard.
A
So
maybe
I
think
the
first
off
we're
kind
of
in
a
state
of
flux
and
a
mad
rush
to
release
4.0,
so
I
wouldn't
propose
opening
a
PR,
but
maybe
if
there
are
people
who
right
now
plan
to
follow
up
and
work
on
this,
we
could
see
if
everyone's
okay,
with
creating
a
Jupiter
lab,
org
repo
for
an
extension
that
does
this
so
that
it's
happening
under
Jupiter
lab.
But
you
know
it's
not
contingent
on.
A
E
And
that
is
a
64
question,
so
maybe
at
this
point
we
could
say
people
think
about
it.
You
know,
and
if
it
sounds
like
something
interesting
to
you,
then
then
let
us
know
next
week.
Another
thing
we
can
do
is
create
an
issue
in
the
Jupiter
lab
repo.
There
is
a
tag
for
extension
idea
every
now,
and
then
we
get
a
new
person
that
comes
by
and
says.
Oh,
this
is
a
great
extension
idea
and
you
know
runs
with
it.
A
If
you
work
on
a
team
that
does
Jupiter
things
and
you're
looking
for
a
thing
to
do,
this
might
be
a
high
impact
one.
So
you
know
go,
go
back
and
talk
to
your
team
and
see
if
they
are
on
delivery.
Maybe
funding
you
to
work
on
this
because
it
does
seem
pretty
cool.
It
does
seem
like.
If
we
don't,
there
will
be
lots
of
ad
hoc
attempts
to
achieve
what
this
wants
to
achieve
anyway,
because
people
want
to
type
something
in
the
notebook
cell
and
get
something
in
the
output.
E
And
honestly,
this
is
helping
people
migrate
from
the
classic
notebook
where
all
these
apis
were
available.
You
know
it's
a
code
that
was
running
from
the
kernel.
B
E
D
Maybe
maybe
some
of
the
people
on
The
Notebook
7
effort
with
C
value
in
this
in
terms
of
porting
existing
extensions
like
actually,
if
you
were
able
to
do
it,
or
at
least
we
contribute
to
what
kind
of
apis
could
be
useful
to
have
right.
If
we
have
this
this
and
this
I
should
be
able
to
Port
most
of
these
extensions
over
right.
E
So
I
think
the
idea
is
out
there
now
I
think
a
good
Next
Step
would
be
posting
an
issue
on
the
jupyter
lab
repo
that
condenses
this
conversation
down
and
people
can
add
like
why
they
think
it's
valuable
and
then
and
then
and
then
we
we
have
the
start
of
an
idea.
That's
Consolidated
from
several
different
sources
here.
A
A
No
I
don't
believe
it
is.
This
is
more
like
when
we
vote
to
bring
an
extension
in,
except
it's
voting,
to
work
on
an
extension,
but
until
people
volunteer
to
do
that,
work,
there's
no
point
right
in
creating
a
blank
repo,
but
I
I
I
think
this
is,
as
as
Jason
said,
an
extension
idea
really,
and
so
that
doesn't
strike
me
as
Jeff
yet
but
I
think
what
might
be
the
job
is
if
the
implementation
is
good
everyone's
on
board
and
we
want
to
say
cool.
E
One
other
piece
of
feedback
I
would
love
to
solicit
William.
You
represent
another
front
end
for
Jupiter.
If
we
had
an
AP,
if
we
had
a
mime
type
that
you
know
proposed
that
there
would
be
an
API
available
to
the
JavaScript
code
in
this
particular
mic
time
type.
That
would
allow
interaction
with
the
kernel
or
you
know,
getting
a
Dom,
the
Dom
element
for
the
output,
or
you
know
some
of
these
basic
API
minimal
API
that
that
has
mentioned.
Would
you
be
interested
in
implementing
it
for.
G
G
G
And
I
also,
when
you
were
mentioning
all
the
mime
types,
it
would
be
nice
to
say
more
about
what
you
know
how
they're
supposed
to
be
rendered
and
what
they
actually
are
because
I
think
Colonel
authors
to
some
extent
kind
of
I
mean
there
may
be
mutually
incompatible
interpretations
of
mime
types
and
then
that
makes
it
difficult
for
front
ends
because
you
have
to
say:
oh,
if
it's
the
you
know,
Julia
kernel
interpret
things
one
way
and
if
it's,
the
r
kernel
interpret
them
differently,
which
is
not
the
way
it
should
be.