►
From YouTube: Octant Community Meeting - March 31st, 2021
Description
Octant community meeting is held weekly. We discuss and talk about the current state and future of Octant, demo upcoming features and releases, and preview new ideas we are considering for Octant.
Meeting agenda: https://hackmd.io/CzaPxtmXT_SW8nEpdwvGzw?view
A
All
right
welcome
everybody
to
the
march
31st
octan
community
meeting.
We
have
a
nice
short
and
sweet.
Today
we
are
in
the
middle
of
our
0.19
sprint,
which
is
we're
hoping
to
release
on
april
7th,
as
mentioned
last
week,
progressing.
That's
pretty
good.
We
intentionally
kept
it.
You
know
scaled
scoped
to
a
minimum
set
of
issues
that
were
missed
for
odd
18,
but
that
people
really
wanted
to
see.
Plugin,
authors
and-
and
some
other
folks
wanted
to
see
available
sooner
than
than
like
a
standard
like
three
to
four
week.
A
Release
cycle
so
we're
doing
that
shorter
one
on
the
seventh
to
get
some
of
those
features
out
and
that
work
is
progressing
pretty
well.
We
have,
I
think
we
have
three
or
four
pr's
up
at
the
moment.
A
Yeah,
there's
a
pr
for
the
signpost
implementation,
pull
request
for
the
plugin
state
and
some
new
ones.
Actually
that
came
in
yesterday
and
today
that
I
haven't
even
looked
at
so
yeah
we're
things
are
looking
pretty
good
forms
refactoring,
which
is
one
that
I
know
a
lot
of
people
are
interested
in.
A
Anyway,
very
I'm
very,
I
had
my
first
vaccination
shot
yesterday.
I
feel
I
think,
I'm
like
very
groggy
and
like
still
a
little
like
feeling
the
effects
of
it,
but
a
little
lower
energy
than
normal.
So,
let's
see
back
into
the
what
we're
going
to
talk
about
nightlys
yeah,
they
were
broken
sam
fix
them.
B
They
were
fixed
for
yesterday,
so
everything
before
yesterday
is
bad
and
I
think
our
retention
period
is
like
five
days.
I
believe
it's
either
five
or
thirty.
I
don't
I
don't
know
I
might
have
the
numbers
crossbar,
but
regardless,
if
you're
looking
for
a
nightly,
just
note
that
there's
going
to
be
a
blackout
period,
probably
for
the
last
week,
because
this
broke
since
we
did
the
migration
to
go
in
bed-
and
we
didn't
fix
this
for
a
gut
releaser.
A
Yeah,
I
think
I
think
it
is.
I
want
to
say
it's
a
week
that
we
keep
yeah
looks
like
we.
We
just
hit
the
the
the
time
so,
like
they've
been
broken
since
the
23rd
or
the
24th,
we
had
a
successful
one
on
the
23rd
and
they
got
fixed
on
the
31st.
So
so
it
was
just
yeah.
They
were
just
about
to
fall
off
and
have
nothing
in
there,
so
it
was
good
at
least
there's
there's.
At
least
there
was
the
23rd
one
in
there
still.
So
that's
good
yeah.
A
Thanks
for
for
fixing
that
tim,
let's
see,
and
then
I
don't
really
have
any.
Does
anyone
else
from
the
team
have
anything
they
want
to
add
before
we
move
on
to
the
demo
from
from.
B
All
right
cool,
so
I
will
take
over
for
a
second
here.
Let
me
share
a
screen
and,
let's
see,
I
think
this
is
good
enough
cool
all
right.
So
let's
talk
about
graphs,
because
this
is
something
that
we've
talked
about
in
octane
before.
Let
me
actually
just
get
to
the
interesting
part.
So
then
we
can
have
it
for
quick
purposes.
B
This
is
a
graph
on
opt-in,
it's
new,
it's
got
buttons
and
it's
got
titles
and
legends,
and
it's
got
on
hover
things,
and
this
is
all
fake
data,
so
this
is
ecstatically
rendered
data.
This
is
not
particularly
exciting,
but
this
is
just
kind
of
to
show
that
it's
kind
of
trivial
to
get
a
plot
up
and
running
with
a
graphing
library
onto
octant.
Well,
not
trivial.
B
It
took
like
maybe
two
hours,
but
it
like
once
it's
up,
it's
kind
of
self-supported
right
like
it's,
just
like
you,
just
install
the
module
and
you
just
register
the
component
and
the
export
and
it
works.
So
the
reason
why
this
for
context
for
anyone
who's,
marching
the
reason
why
we
actually
haven't
jumped
on
like
something
like
this
sooner,
whether
it's
this
plotting
library
or
another,
is
really
because
of
the
way
often
works
right
like
if
I'm
looking
for
say
like
something
like
cpu
usage
over
time.
B
But
now
I
kind
of
want
to
revisit
this
a
little
bit
right,
because
the
idea
is
that,
even
though
there
might
not
be
kubernetes
specific
things
that
are
useful
in
the
context
of
a
graph,
there
might
be
other
things
that
people
might
be
using
like.
This
could
be
a
plug-in
thing
right,
like
it
doesn't
necessarily
have
to
be
metrics
or
something
kubernetes
related
right,
like
something
super
basic
that
we
could
come
up
with.
Theoretically
is
like
as
a
proof
of
concept
it's
like.
B
If
we
go
to
events
or
something
well,
I
have
no
events,
but
if
I
had
events
here,
maybe
I
do
have
something
cluster
overview
or
maybe
not.
Let's
see
events.
No,
maybe
I
just
don't
have
any
events
but
like
if
I
let's
say
I
had
an
event
right.
So,
let's
see
if
I
can
even
force
something
to
happen
here.
Like
I
don't
know,
let's
say
I
go
to
this
pod
and
I
delete
it,
and
hopefully
this
creates
an
event
cool.
So
now
there's
an
event
right.
B
Maybe
we
could
have
something
like
a
histogram
right
where
we
kind
of
show
these
events,
and
it
could
be
useful
if
there's
a
crash
through
back
off
somewhere.
Then
the
events
for
a
crash
of
back
off
would
pile
up
super
high
right.
So
like
there
are
things
we
can
do
already.
That
might
not
necessarily
rely
on
persistence,
but
the
idea
here
is
one
it's
kind
of
like.
If
we
have
something
like
this,
I
think
we're
gonna
need
to
think
about
two
things
right.
B
One
is:
how
do
we
make
sure
that
this
rendered
graph
renders
that
same
data,
even
after
the
user,
navigates
away
from
the
page
right?
So
even
after
this
graph
component
that
we'd
be
using,
is
destroyed
and
recreated?
Is
there
a
way
to
persist
that
data
between
views
right?
So
if
I
go
back
like
to
that
say
that
dummy
chart
there,
so
let's
say
I
go
to
pods
and
go
back
and
to
our
tab
here
right
like
like.
B
If
this
were
not
static
data,
would
I
be
guaranteed
to
see
this
data
again
and
currently,
with
our
implementation?
Probably
not
like
we'd,
probably
need
at
some
sort
of
angular
service
that
registers
every
single
plot
that's
been
rendered
before,
like
maybe
we
create
like
a
hash
map
with,
like
the
key
being
some
random
hash,
that
maps
to
each
chart
that's
been
generated
before
and
then
like
the
data
that
it's
shown
and
then
like
we
kind
of
diff
the
data.
The
next
time
it
gets
shown
again.
B
So
it's
I
guess,
like
it's
harder,
it
gets
hard
very
quickly
once
we
start
thinking
about
not
static
data
right
or
we
start
thinking
about
this
in
a
real-world
use
case.
So
I
guess
what
I
want
is
like.
Is
this
something
we
want
to
invest
on
like
now-ish
like?
Is
this
the
right
time
to
start
talking
about
this?
Maybe
we,
you
know
we
always
say
like.
B
Oh,
we
could
throw
this
in
the
design
dock
and
we
could
certainly
do
that
as
well,
but
I
just
want
to
see
like
what,
if
there
are
any
thoughts
on
like
you
know
like,
is
there
like
something
that
we
think
that
should
have
a
graph
right
now
and
often
that
doesn't
have
one?
And
maybe
we
should
just
put
that
in
there.
B
It
doesn't
necessarily
have
to
be
exposed
in
the
form
of
a
plug-in
component
either
right
like,
but
we
could
even
just
start
small
and
use
it
internally,
like
think
of
spots
within
octa,
that
it
could
be
useful
and
then
over
time
we
can
slowly
start
to
expose
the
api
through
a
plug-in
user
since
it'd
be
a
little
bit
easier
to
think
about
that,
going
right
off
the
bat
and
the
cool
thing
about
it,
and
this
one
I'm
using
something
called
plotly,
which
is
kinda
cool.
B
I've
used
plotly
before
back
in
the
python
days
of
jupiter
notebooks.
They
make
some
really
nice
interactive
graphs,
just
out
of
the
box
and
they've
got
a
nice
angular
library
here
and
the
installation
instructions
are
pretty
they're,
not
straightforward,
but
like
yeah.
If
you
want
to
try
this,
I
could
also
push
this
up
as
a
branch
somewhere.
B
But
if
you
really
wanted
to
try
this
yourself,
you
want
to
make
sure
to
do
it
through
plotly,
via
window
module
as
the
installation,
because
of
the
way
that
we
compile
our
typescript.
This
is
probably
the
most
straightforward
way
to
do
it.
Otherwise,
they're
gonna
run
into
a
lot
of
like
transpile
type
errors
in
the
console,
and
you
can
kind
of
compare
this
to
like
say:
ngx
charts
this
one
ultimately
is
a
more
popular
library,
and
this
one
is
even
more
lightweight.
B
So
plotly
is
a
very
expensive
library
to
use
as
well.
So,
like
that's
also
another
consideration
like
this
bumps
our
bundle
to
well
over
three
megs,
whereas
this
one
is
an
svg
library.
So
it's
much
more
lightweight
and
it's
still
still
pretty
nice.
B
I
mean
like
I
saw,
I
see
like
the
demos
on
stack
blitz,
but
I
guess
what
I'm
saying
here
is
that,
like
I'm,
not
particularly
inclined
to
use
any
particular
chart
library,
since
we
don't
actually
know
what
charts
we
want
in
the
first
place,
so
that's
where
I
want
to
start
like
figure
out
what
charts
we
want,
then,
from
there
to
see
if
there
are
any
chart,
libraries
that
might
support-
and
I
I'm
pretty
sure
like
most
of
these
are
pretty
good
like
it
might
just
be
a
mood
argument
to
like
pick
one
over
the
other
but
like
if
there's
a
specific
chart,
that's
supported
on
one
and
not
the
other.
B
Maybe
this
is
something
we
want
to
get
right
from
the
get-go
and
then
from
there.
We
can
talk
about
plug-ins
and
see
if
plug-in
authors
have
something
to
say
about
this.
So
that's
that's
it
in
a
nutshell.
Thank
you
for
coming
to
my
ted
talk.
Let
me
know
if
you
have
any
feedback
on
this.
I
can
also
push
this
code
somewhere
for
people
who
want
to
try
it,
but
I
want
to
start
playing
around
with
the
sync
idea.
B
Just
just
a
rudimentary
concept
to
see
if
I
can
try
to
get
like
dynamic
data
feeding
through
this
and
like
start
persisting,
data
between
views,
I
think
that'd
be
a
next
step.
That'd
be
kind
of
a
fun
code
thing
to
think
about.
So
that's
it
are
there
any
questions
about
what
I
did
here.
It's
not
a
lot
honestly.
A
I
know
I
think
I
think
this
is.
I
think
it's
really
neat.
I
think
it's
something
that,
like
you
said,
we've
talked
about
a
couple
times
kind
of
casually,
but
never
really
gave
thought
to
it.
I
think,
as
we
as
we
start
to
invest
more
in
the
local
and
the
in
the
application
experience,
I
think
we
can.
I
think
we
can
start
to.
I
think
we'll
have
a
better
ability
to
connect
to
services
that
can
provide
data
like
this.
A
I
do
think
we
want
to
avoid
storing.
I
we
want
to
avoid
being
the
data
store
for
any
like
time
series
to
data
or
anything
like
that,
but
I
really
like
the
idea
of
providing
kind
of
the
building
blocks
for
people
and
saying
you
know:
here's
just
like
we
do
with.
I
think
we
have
like
the
donut
right
like
you.
Can
the
donut
started
out
as
an
internal
thing,
and
then
it
got
added
so
that
plug-in
authors
could
use
it
and
then
it
got
out
it
got
extended.
A
So
now
you
can
change
thickness
and
colors
and
all
of
these
right,
and
so
like.
I
like
the
idea
of
finding
something
internal
to
octant,
that
we
feel
would
improve
the
overall
user
experience
by
representing
it
as
a
chart
or
graph
and
then
bringing
that
in
and
then
exposing
it
to
plugins
and
then
exposing
extra
features
on
it
and
just
like
that
process,
I
think
worked
really
well
for
for
a
lot
of
the
various
components
that
we
add
to
oxygen
right.
A
We
put
it
in
auction
first
and
then
we
expose
its
plug-ins,
and
then
we
extend
its
capabilities.
I
think
we
could
probably
do
that
here
as
well,
like
identify
one,
do
it
and
then
can
like
just
continue
to
expand
on
that?
I
talked
to
milan
milan's
out
this
week,
but
I
talked
to
him
last
week
before
he.
A
It
was
last
week
or
the
week
before
about
because
milan
had
previously
worked
on,
like
a
data,
visualization
library
and
I
talked
to
him
about
creating
like
thinking
about
some
of
those
ideas
from
that
database
library
and
what
what
areas
of
octane
might
benefit
from
some
of
that
as
well.
So
I
think
I
think
I
I
don't
know
if
now
is
the
time
to
like
invest
heavily
in
it.
A
I
think
we
have
some
other
things
that
are
more
important
and
more
critical
path
for
us
right
now,
but
I
think,
starting
to
document
our
investments
like
starting
to
document
some
of
these
things,
starting
to
create
proof
of
concepts
and
prototypes
and
like
use
some
of
our
times
experimenting
and
researching
and
learning
things
to
like
investing
some
of
that
time
into
the.
A
Adding
features
like
this
time,
I
think,
is
a
good
use
of
time.
I
think
I
think
in
the
past,
we've
talked
about
it
and
showed
them,
and
and
but
that
never
really
went
like
having
a
working
demo
always
seems
to
take
things
a
lot
further
than
than
just
like
saying,
oh
yeah,
that
would
be
nice,
so
I
think
I
think
the
fact
that
you
have
like
a
skeleton
of
like
hey
here's,
here's
plotley
embedded
into
octane,
okay.
A
B
Yeah
yeah
yeah
and
the
this
is
just
more,
I
think,
for
anyone
who
is
watching
this
either
from
like
the
youtube
stream
or
later
through,
recording,
I
don't
think,
there's
anyone
else
in
the
car
right
now.
But
I
think
this
is
just
a
general
call
out
right
like
I
think
the
idea
is
that
we
want
to
shy
away
from
like
metrics
like
we
don't
want
to
like,
say
like.
B
Oh,
we
have
a
prometheus
view
inside
often
right,
like
that's,
probably
not
what
we're
shooting
for
since
that's
well
for
one,
it's
probably
those
metrics
but
would
concern
more
of
a
cluster
operator
than
a
developer,
but
also
for
the
reasons
we
talked
about
earlier
right,
like
it's
hard
for
a
ephemeral,
desktop
application
to
make
a
meaningful
use
of
those
charts
somewhere.
Unless
we
start
thinking
about
how
to
ingest
a
bunch
of
data
at
once,
which
also
doesn't
seem
quite
correct.
B
So
it's
really
more
like
if
there
were
charts
like
what
would
we
be
showing,
I
think,
at
the
end
of
the
day,
I
think
we
need
to
boil
back
down
to
what
is
the
problem.
B
We're
trying
to
solve,
rather
than
just
say
here
are
charts,
go,
have
fun,
so
just
a
general
call
for
brainstorming
and,
of
course,
like
always
feel
free
to
open
issues
or
bang
on
slack,
because
the
I
because,
generally
right,
the
only
way
that
we
know
how
to
invest
in
more
into
a
particular
feature
is
to
get
that
input.
Otherwise,
we
kind
of
in
in
a
way
like
our
hands,
are
tied
with,
like
the
last
thing
that's
been
requested
by
someone
else
so
anyway,
that's
that's
all
I
got
for
today.
A
Yeah-
and
I
think
that's
a
good-
that's
a
good
point,
sam,
like
the
four
how
we
might
use
this
in
octant
yeah.
That's
that's
different
than
I
think
the
the
here's.
Here's
here's
a
bunch
of
components
go
have
fun,
is
the
correct
approach
for
for
plugins
right,
because
people
are
creating
plugins
that
I
would
have
never
even
thought
of
to
create
and
they
want
to
use
the
components
in
ways
that
I
never
even
thought
of
using
them.
A
A
Customizable
and
flexible
is
is
an
important
part
of
the
plug-in
offering
I,
but
I
think,
avoiding
the
like.
We,
we
can't
do
that
necessarily
for
or
we
don't
want
to
be
doing
that
for
for
the
views
that
we
are
creating
in
octane.
We
don't
just
want
to
start
adding,
charts
and
graphs
just
because
we
can
yeah.
They
need
to
actually
serve
a
purpose
and
be
useful.
A
So
I
yeah
I
agree
with
with
that,
but
it
is.
It
is
still
useful
to
have
them
gen,
similar
to
like
our,
how
we
add
clarity,
components
that
we
might
not
necessarily
use
an
octant
just
so
that
plugin
authors
can
have
access
to
them.
I
think
that
is
still
will
be
an
important
part
of
of
the
charting
graph
stuff
in.
A
A
Yeah,
so
I
don't
really
have
anything
else:
was
there
any
did
anyone
who
was
working
on
any
of
the
open
pr's
want
to
talk
about
them
or
demo
them
at
all
or
put
just
put
people
on
the
spot?
I
don't
I'm
okay
with
doing
that.
B
I
have
some
comments
on
vikram's
pr.
I
think
it's
like
what
two
two
four
four
plug-in
request
date:
I've
been
sitting
on
it.
I've
been
like
sitting
on
it
back
and
forth,
like
on
one
hand,
it's
like
yeah.
It
works
the
way
that
one
would
expect
it
to
and
actually
can
share
it
real
share
screen.
Since
I'm
talking
about
it
right
now,
desktop
one
plugin
request
dates.
B
I
think
it's
just
for
the
team
since
we're
all
here
right,
like
I
generally
don't
try
to
say
like
I
don't
like
it,
without
providing
a
better
alternative,
and
in
this
case
I
actually
don't
have
one,
which
is
why
I
haven't
really
said
anything
and
I've
just
sat
on
and
slept
on
a
little
bit,
but
I
think,
like
one
of
the
concerns,
I
have
right
it's
kind
of
the
way
that
we're
doing
plug-and-stay
right
like
we're
doing
state.getfilter.state.gov
namespace
and
really
we
could
even
just
extend
this
logic
further
right
like
if
we
go
into.
B
Let
me
see
if
we
can
do
this
here,
nope
yeah.
Actually
we
can
state.go.
B
B
It's
called
this
get
namespace
and
then
it
probably
called
like
get
filters,
but
really
we
could
extend
it
to
say
we
want
all
of
this
right
like
there
will
be
a
day
where
we
could
say,
okay,
what
about
context
or
what
about
get
just
to
get
content
path,
just
as
a
handy
method
and
I'm
just
trying
to
think
think
like
long-term
scalability
right
like
if
I
want
to
just
have
all
of
this.
B
What
would
that
look
like
and
it
gets
a
little
weirder,
because
if
we
think
back
to
our
send
alert
pattern
right
like
we
have
this
some
actions
right
things
that
do
things
with
the
current
opt-in
state.
That
requires
a
client
id,
and
we
do
this
fancy
hack
to
get
the
client
id
from
the
request
context.
B
And
then
we
send
the
alert
to
the
given
client
id,
because
that's
the
only
way
we'll
know
to
send
a
correct
alert,
but
this
could
also
apply
to
some
of
these,
but
not
all
of
these
right
like
so,
for
example,
regardless
of
which,
well
maybe
that's
not
true,
yeah.
I
think.
Actually,
I
retract
that,
like
set
context,
could
be
you
could
have
like
different.
B
B
They
would
also
use
a
very
similar
pattern
with
what
vikram
just
did
and
I'm
trying
to
figure
out
if
there's
a
way
to,
even
just
at
some
point,
either
refactor
the
code
to
just
give
the
octane
state
to
a
plug-in
and
say:
okay,
you
now
have
access
to
that
websocket
state
do
whatever
you
want
with
it,
since
it's
kind
of
the
current
connection
already
so
so
I
think,
like
there
are
two
parts
here
like
one
I
think
like.
B
I
think
that
pr
is
okay,
but
I
could
also
see
this
in
the
long
term
being
refactored
completely
such
that,
like
we
bump
up
this
because
right
now,
this
is
like
in
internal
octant,
and
that's
probably
why
this
is
difficult
to
wire
up
is
because
maybe
we
just
need
to
move
this
into
a
package
and
yeah.
We
move
this
up
to
package
or
we
move.
B
We
somehow
have
the
websocket
states
ready
as
part,
and
really
this
also
goes
back
a
level
further
if
we
go
into
dash
dot,
go
the
reason
why
this
is
hard
is
because
of
this
file,
which
we
always
keep
coming
back
to
like
every
time,
something's
hard.
It's
because
of
this
file.
Specifically,
I
think
it's
like
plugin
dot,
plugin
api
dot,
something.
B
Yeah
here
right
so
like
this
line,
437
to
442
of
this
plug-in
dashboard
service
is
kind
of
all
of
the
internals
of
octane.
That
plug-ins
have
access
to
right,
and
so
the
reason
why
we
can't-
or
the
reason
why
we
don't
have
this-
is
because
we
initially
we
have
this
websocket
client
manager
and
then
I
believe
we
do
stuff
with
a
website,
client
manager
and
just
a
nit
plug-in
later,
whereas
we
really
just
want
whatever
this
web
socket
state.
B
That's
been
created
by
this
method
to
be
already
part
of
this
plugin
service,
so
that's
kind
of
where
it's
where
I'm
at
right
now,
so
it's
kind
of
like
I
don't.
I
don't
want
to
be
like
vikram.
This
doesn't
work
because
it
does,
but
at
the
same
time
it's
the
it's
the
yeah,
I'm
just
thinking
more
long
term
about
how
we
want
this
to
look.
So
I
think
ultimately,
I'd
probably
like
for
this
release.
B
I
really
just
don't
want
to
mess
with
this,
because
I
keep
saying
there's
going
to
be
a
dash.go
refactor
and
I
just
haven't
had
either
with
the
motivation
or
maybe
I'm
just
not
smart
enough
to
do
it
or
a
combination
of
the
above.
So
there
like
this
is
like
this
is
the
problem
that
we're
trying
to
solve
it's
it's
the
way
that
octan
is
running,
not
because
the
pr
is
bad.
D
I'm
really
glad
he
brought
it
up
because
when
I
was
looking
into
you
know
the
different
ways
of
implementing
it
and
I
was
tracking
it
how
state
could
be
used
to
pass
through
plugins.
I
found
the
same
thing
like
api
and
you
know
the
website.
Client
and
plugins
are
initialized
at
the
very
top
level
and,
like
you
know
they,
it
was
kind
of
hard
to
pass
off
the
state
from
five
levels
below
all
the
way
to
the
plug-in
manager.
D
A
I
could
see
us
lifting
up
a
like
a
state
reader
interface,
so
I
think
I
think,
having
an
internal
state
interface.
There
is
still
going
to
be
useful,
but
I
think
then
creating
a
state
reader
that
exposes
all
of
the
get
options
right
at
the
at
the
package
level,
and
then
those
are
then
hydrated
underneath
by
the
websocket
manager
right.
The
client
manager
can
then
create
all
of
the
instances
and
everything
that
that
are
needed
underneath
to
then
satisfy
that
state
reader.
A
That
would
be
like
the
first
first
refactor
that
I
would
consider
when
when
people
go
to
like,
I
don't
think
we
should
do
that
for
for
this
pr,
I
agree
with
sam.
I
think
that
this,
the
the
public,
the
public
apis
that
we're
creating
to
interact
with
this
are
good.
It's
it's
more
about
the
internal
implementations
that
need
to
be
refactored
and
worked
out,
but
also
we
can
change
them
like
we're
still
pre
1.0.
A
We
can
as
long
as
we
announce
them
and
and
make
sure
that
people
know
that
we're
changing
apis
and
communicate
it
well.
We
can
change
them,
nothing's,
nothing's,
concrete
yet,
but
yeah.
I
think
I
think
getting
that
getting
that
whole
dash.go
refactored
is
is
is
a
process.
It's
already.
A
It's
already
received
like
like
it's
it's
it's
happening
in
phases
which
can
make
it
like
it
can
seem
like
progress
is
not
happening
there,
but
you
know
even
where
it's
at
today,
it's
already
easier
to
go
in
and
start
to
extract,
more
pieces
and
refactor
more
pieces,
and
I
think
we'll
continue
that
effort
and
and
we're
just
going
to
have
to
yeah
the
reason
it's
difficult
to
refactor.
A
That
package
is
because
it's
central,
it
is
the
central
package
that
wires
everything
together
and
and
creates
all
of
the
composition,
layers
and
and
instantiates
all
the
dependencies
and
and
threads
them
through
to
the
various
things
and
and
in
some
places
we
do
a
good
job
of
keeping
those
things
isolated
and,
like
here's,
your
dependency,
it
gets
injected
here
and
then
in
other
places,
where,
like
here's,
your
dependency,
it
instantiates
some
stuff
internally
and
then
it
returns
that
to
another
thing
that
we
injected,
which
then
uses
that
internally
and
so
like.
A
We
break
the
pattern
like
we
break
that
dependency
injection
pattern
and
and
the
the
layers
of
composition,
kind
of
kind
of
fall
down,
and
we
leak
the
abstraction
kind
of
leaks
a
little
bit.
But
it's
getting
better.
I
think
parts
of
it
have
already
been
refactored
in
a
way
that
is
beneficial,
but
the
the
I
think,
the
I
think
the
hole
in
it.
A
We
have
this
whole
like
in
it
api
in
it
loop
where
we
like,
we
start
and
in
it,
and
check
and
and
wait
and
do
and
like
with
all
of
this
communication
and
like
like
the
way
we're
doing
it
now
is
like
a
combination
of
like
new
approaches
and
shimmed
old
approaches
so
yeah.
It's.
A
It's
not
great,
but
it's
getting
better
and
I
think
it's
it's
yeah.
I
I
agree
with
your
assessment
overall
sam
and
same
same
for
you
vikram
like.
I
think
that
what
you
all
are
seeing
as
you
go
in
to
approach
some
of
these
problems
and
like
them
being
difficult
and
then
being
like.
It's
a
challenge
to
get
that
state
information
that
that
client
information
wired
through
into
and
surfaced
in
a
plug-in
as
a
direct
result
of
of
this
kind
of
legacy
code
that
needs
some.
Some.
B
B
Yeah
so
yeah,
and
just
to
extend
on
like
that
conversation,
a
little
further
right,
there's
also
two
other
competing
ideas
with
go
like
the
first
thing
that
we
want
to
do
is
to
make
it
more
testable.
This
has
been
a
pain
point
for
some
time
and
the
other
piece
of
it
is
also.
We
want
the
octen
to
run
as
a
standalone
server
without.
B
Knowledge,
because
then
we
can
do
some
very
plug-and-wise.
Some
very
interesting
things
can
happen
right
where,
like
now,
you
don't
even
need
a
cube
config,
you
don't
need
kubernetes
and
you
could
even
have.
I
think
one
of
the
ideas
juggled
was
like.
B
Oh,
you
could
even
have
octane
as
a
thing
that
creates
clusters
on
kind,
and
you
can
have
octane
as
a
thing
that
can
kind
of
be
very
similar
to
like
spotify's
backstage,
where
you
just
kind
of
start,
like
it's
like
just
a
platform
for
people
to
build
components
on
and
developers
do
whatever
they
want
on
it,
and
it
just
becomes
this
blank
check
for
whatever
people
want
to
do
so.
B
That's
so
those
kind
of
tie,
hand
in
hand,
I'm
not
sure
what
order
they'll
happen
in
it'll
happen
eventually
someday
yeah,
and
I
guess
the
other.
I
guess,
while
we're
also
on
the
topic,
I've
also
looked
into
the
signpost
pr
as
well.
Actually,
both
since
we're
already
talking
about
prsa,
I
think
signpost
looks
mostly
great.
I
think
most
of
them
are
just
picks
like
just
making
sure
to
catch
like
making
just
making
sure
that
yeah.
You
know
like
if
someone
like,
writes
a
signpost
with
a
trigger
badly.
B
It
doesn't
panic.
We
just
want
to
you
know
to
avoid
users
from
being
able
to
break
octant
just
accidentally
as
much
as
possible
and
then
the
other
one
for
felipe's
pr
with
a
create.
I
realize
I'm
not
sharing
my
screen
at
all.
The
other
one
is
fully
based.
Pr
is
create
a
util
package
to
link
components
and
this
one's
kind
of
my
fault.
B
Like
I
told
them,
there
was
two
ways
to
do
it,
one
it
was
kind
of
like
either
you
can
generate
the
paths
manually
like
so
which
I
sat
down
and
I
looked
at
and
I
was
like
yeah
it
probably
for
maintainability
reasons.
We
probably
just
don't
want
to
do
something
like
this,
even
though
it's
probably
easier
to
grok
the
first
pass
around.
B
B
It
creates
link
essentially
using
the
module
manager
kind
of
similar
to
how
our
new
link
components
work.
Yeah,
like
we
can
do
this
link
generator.object
path
so
now
we're
using
our
mod.
We
expose
the
module
manager
indirectly
to
a
plugin,
and
I
think
this
will
just
create,
or
this
will
just
prevent
any
of
the
hard-coded
type
of
work
needed
and
just
make
things
a
little.
You
know
it's
essentially
the
same
way
the
javascript
plugin.
B
Does
it
right
now
and
I
think
right
now,
the
only
thing
that's
missing
is
really
like
what
what
do
we
populate
the
new
link
with
right
so
like
it's
just
missing
some
other
methods
to
be
exposed
so
like
if
we
want
the
link
to
have
text
or
something,
but
I
think
for
the
most
part,
I
prefer
this
method
over
the
original,
but
I
think
either
way
is
either
way
works
in
the
short
term.
B
Anyway,
that's
kind
of
it.
That's
the
only
that's
all
the
stuff
that
I've
had
time
to
look
at.
E
I
have
a
question
about
that:
signing
post
okay.
Well,
let
me
share.
E
E
I
have
to
add
this
click
me
button,
because
the
only
thing
that
happens
when,
when
I
gonna
to
make
sure
that
people
know
the
icon
is
clickable,
is
that
the
cursor
change?
E
So
yes,
and
that's
what
some
point
out
here,
but
I'm
not
really
sure
what
to
do
with
that,
because
you
we
we
we
allow,
I
mean,
like
clarity,
provides
it
says
that
we
have
to
use
this
type
of
this
type
of
icon
and
as
soon
as
if
we
change
anything,
it
should
become
blue
and
to
make
sure
that
and
with
hover
it
should
become
blue.
E
But
at
this
point
I
was
adding
the
I
was
pretty
much
adding
the
we
can
use
any
icon
and
we
can
put
a
like.
We
can
set
any
color
in
in
the
icon.
So
I
was
wondering
if
for
this
vr,
I
should
make
it
always
gray,
even
even
if
the
user
sent
a
nikon
or
anything
with
with
a
specific
color
and
just
create
a
hover
that
will
change
the
color
of
the
icon
as
soon
as
as
soon
as
somebody
covered
with
the.
B
Don't
necessarily
have
like
it
doesn't
necessarily
have
to
be
an
icon
based
on
how
this
works
right.
That's
also
kind
of
something
that's
interesting
to
think
about
right
like
well.
What
if
this
isn't
an
icon?
What
would
it
be?
B
I
could
definitely
see
this
could
be
like
something
like
say
like
for
text
almost
right
so
like
you
could
have
like
say
kind
of
like
one
of
those
like
define
the
text
right
like
let's
say
you
want
to
have
like
a
sign
post
with
a
message
that
just
tells
you
what
that
thing,
what
that
piece
of
text
means
right.
That
could
be
another
use
case.
So.
D
B
But
like
there
could
be
more
that
we
haven't
thought
of
right
so
like
it's
important
to
like
generalize
this,
not
just
to
an
icon,
because
for
something
like
that,
you're
not
going
to
have
to
click
me
message
right.
Your
the
user
would
just
kind
of
have
to
know
that
this
is
something
they
could
hover
and
click
for
a
signpost.
B
The
other
piece
here
is
okay.
What
do
we
do
right
so
like
we?
I
think
clarity's
recommendation
is
just
show
blue
on
hover.
I
think
that's
reasonable,
like
I
don't
like
I'm,
not
a
designer
by
trade
and,
like
so
like
there
might
be
other,
like
accessibility
concerns
or
even
a
better
way
to
do
this
in
the
that
I
don't
have
in
my
toolkit
right
but,
like
I
think,
like
just
leaving
it.
B
So
it's
more
so
it
just
grabs
people's
attention,
but
I
think
right
now
just
do
the
official
clarity
recommendation
so,
but
if
it's
an
icon,
just
give
it
that
clarity,
blue
color
or
even
any
component,
really,
if
it's
possible
right
so
like
it
might
involve
like
some
sort
of
css
trickery
to
pass
that
into
this
into
the
trigger
component.
But
it's
possible,
I
think
that's
yeah.
So
I
does
that
answer
the
question.
I
I
know
it's
a
kind
of
roundabout
way.
Yeah.
E
Yes,
I
I
was
thinking
in
doing
the
something
like
different
like
I
don't
know
to
put
a
background
different
or
I
was
thinking
something
like
that,
but
I
wasn't
really
sure
on
what
to
do,
but
if
we
can
do
that,
just
just
change
the
color
to
blue
and
and
and
that's
it-
I
was
thinking
about,
make
it
downpour.
I
I
I
don't
know
I
don't,
but
I
think
that
make
it
make
the
icon
blue
is.
I
think
it
would.
B
B
Yeah
yeah-
and
this
also
this
is
kind
of
like
a
side
note
like
signposts
and
clarity,
are
kind
of
interesting
because,
like
if
you
have
them
inside
another
component,
it
gets
cut
off
like
you
can't
really
control
the
z
index
of
these
signposts.
So
that's
just
also
something
to
think
about.
It's
not
so.
This
is
not
in
our
control.
So
just
kind
of
also
like
something
to
think
about
is
like
at
some
point
we
will.
B
We
will
have
to
issue
like
a
guidance
for
how
to
use
this
pattern
as
opposed
to
hard
coding
it
just
simply
because
they're
you
know,
if
people
put
signposts
in
a
place
where
they
can't
be
seen,
that's
not
really
our
problem.
E
E
Okay,
so
I
just
want
to
make
sure
that,
because
I
thought
the
quality,
if
I
solved
that
problem
of
the
hidden
signpost,
but
I'm
not
completely
sure
I
can't
I
can
check.
B
It
out,
if
it
does
actually
I'm
just
have
octane
running
that'd,
be
news
to
me.
I
mean
that'd
be
kind
of
cool,
so
I
think
the
biggest
complaint
right
now
would
be.
Let's
see
I
know
like
my
screen
is
not
shared
properly
right
now,
but
I'd
have
to
come
back.
Maybe
it
does
yeah
the
biggest
for
the
longest
time
the
object
status
was
hidden
like
was
hiding
our
if
you
go
to
like
the
check
marks
on
our
datagrid
tables
a
lot.
B
A
All
right,
yeah,
so
yeah,
that's
a
great
discussion.
Thank
you.
Everyone!
I
think
that
covered
actually
all
the
open,
well,
the
open
pr's
that
are
in
review
status.
So
that
was
good.
I
don't
have
anything
else,
and
so,
unless
someone
else
does,
we
can
call
it.