►
From YouTube: Octant Community Meeting - March 25, 2020
Description
March 25, 2020
Agenda
Released 0.11
https://github.com/vmware-tanzu/octant/releases/tag/v0.11.0
Upcoming Focus
Documentation
Clarity is the theme:
Seperate user content, creator content (plugins), and core content.
Focus on distinction between octant.dev and markdown in repo.
Clear guide for getting started writing a plugin.
Clear guide for getting started using Octant.
Electron Application
Navigation redesign to support running in electron.
Breadcrumbs
Better CRD handling
Loading without a kubeconfig
Plugin Management
Settings
Plugin API v1
Address the outstanding issues for the v1 epic.
Allow plugins to provide HTML/JS assests (aka WebComponent)
Documentation (see above)
Next Up
Resource Editing
Resource Viewer
Workload Viewer
Object Status
Future
In-Cluster
https://github.com/vmware-tanzu/octant/tree/in-cluster-proposal
Octant Office Hours
https://calendly.com/wwitzel3/octant-office-hours
every Thursday from 13:00-17:00 EDT
Demo
Milan - Vertical navigation updates. https://github.com/vmware-tanzu/octant/issues/340
Open Q&A - add your questions here
[andy shiefelbein] Ability to run raw html / javascript as a plugin (https://github.com/vmware-tanzu/octant/issues/695)
Is it possible to do standard html / javascript without the need to use the octant wraper for elements?
Not yet, but we want to and will enable this. Likely as some kind of WebComponent. We’ll have to think about it a bit more. Will update the issue accordinly.
[sfoo] What do we think about using https://compodoc.github.io/compodoc-demo-todomvc-angular/ as a way to document Angular components?
Pros:
Cons:
A
Hi
everyone
and
welcome
to
another
episode
of
the
octant
community
meeting.
Today
we
get
a
bunch
of
stuff
that
we
want
to
cover.
Of
course,
we're
going
to
talk
about
the
0.11
release,
our
our
upcoming
focus
and
we
have
a
DNA
demo
as
well
from
Milan
at
the
end
of
this,
and
if
you
have
anything
that
you
want
to
add
to
the
agenda,
please
look
at
the
agenda
that
I
shared
in
the
chat
there
and
I'll
share
my
screen
as
well
see
ultram
beauty
agenda
as
we
go
through
it.
B
So
there
is
a
lot
of
good
changes
in
there.
A
lot
of
speed
improvements,
some
reworking
of
how
terminals
were
working.
We
also
replaced
it.
The
existing
yamo
viewer,
with
a
read-only
version
of
Monaco,
a
lot
of
these
things
we've
been
talking
about
for
on
the
on
the
meet
up
meetings
here,
but
just
for
those
who
who
aren't
familiar
just
joining
for
the
first
time
or
watching
this.
B
For
the
first
time,
this
last
release
was
focused
on
making
a
lot
of
speed
improvements
and
just
kind
of
usability
improvements
around
the
yamo
viewer
terminal,
upgrading
to
clarity,
9
and
creating
the
electron
application
stub,
which
was
all
part
of
upgrading
clarity
and
an
angular
9
and
clarity
3.
So
all
of
that
has
been
has
been
released
in
own
11.
B
There
was
a
couple
I
think
some
issues
came
in
or
right
after
this
release
that
have
been
since
fixed
minor,
bugs
and
documentation
things
that,
but
that
have
been
merged
in,
but
so
far
this
this
release
has
been
doing
well.
For
us,
there
was
I
want
to
highlight
and
call
out
that
there
was
some
breaking
API
changes
around
the
plugins.
B
Specifically
the
call
to
get
stor
and
how
the
path
is
accessed.
When
you
are
looking
at
requests,
it
was
changed
from
a
property
into
a
method.
This
was
done
to
allow
for
proper,
mocking
unit
testing
of
plugins.
Another
thing
that
was
added
to
help
with
that
was
we
changed
where
the
or
we
changed
on
the
logging
interface
was
where
it
was
located
essentially,
and
we
moved
it
from
the
internal
logging
package
out
to
package
log.
So
thank
you
to
to
Jordan
who
worked
on
that.
B
That
was
he's
on
this
on
here
now
and
so
really
appreciate
that
work.
I
think
Jordan
also
did
the.
There
was
another
thing.
Thank
you
yeah
that
persistent
volume
printer,
so
that
was
all
it
was
all
really
really
useful
yeah.
So
this,
oh
and
I,
do
want
to
call
out
the
work
that
Milan
did
on
the
logging
interface
to
me
in
my
head.
The
logging
stuff
is
has
has
been
in
there,
but
this
was
part
of
our
on
11.
B
You
can
now
do
searching
and
filtering
and
grepping
through
logs
in
in
the
analog
viewer,
so
that
the
huge
improvement
over
what
we
had
before
what
we
had
before
was
kind
of
this
plain,
not
really
usable
log
viewer,
it's
just
like
here's,
a
bunch
of
here's.
A
bunch
of
text
goes
do-it-yourself
and
now
it's
you
can
step
through
and
hide
in
filter
matches
and
and
use
regular
expressions
to
to
go
through
things.
B
So
we're
following
that
up
and
the
work
that
I'm
doing
right
now,
which
is
to
make
the
log
or
a
combined
fewer
of
all,
of
the
containers
that
are
running
within
a
pod,
so
that'll,
be
in
part
of
the
next
release,
but
it'll
be
going
into
master
here
very
soon,
so
anyway
feel
free
to
check
out
all
of
the
changes
on
a
release.
Page
there's,
there's
lots
of
fixes.
Sam
did
a
bunch
of
speed
improvements
and
updates
around
page
refreshes
and
load
times
and
and
efficiencies
taking
advantage
of
the
upgrade
we
did
so.
B
B
C
Homebrew
is
done,
scoop
is
done
and
for
chocolaty
I
found
out.
We
were
actually
I,
never
got
notified
of
this,
but
we
are
a
trusted
maintainer.
That
means,
if
it
passes
the
auto
the
Auto
scan
whatever
they
do
to
check
for
malicious
software
on
their
package
manager
just
publishes
so
I
think
our
the
time
is
now
probably
closer
to
two
days
instead
of
a
week.
It
is
oh!
Well,
that's
that's
great.
Yes,
that's.
B
All
right,
moving
on
so
I
wanted
to
kind
of
go
over
quickly.
The
upcoming
focus
that
were
going
to
be
this
is
stuff
we're
gonna,
be
prioritizing,
and
the
next
set
of
work
that
we're
going
to
be
doing.
We
touched
on
this
a
little
bit
in
the
last
meeting,
but
I
just
kind
of
wanted
to
now
go
into
a
little
more
detail.
B
It's
going
to
be
switching
over
to
work
on
it,
so
one
of
them
one
of
the
big
focuses
which
which
we
were
intending
to
get
to
known
at
11:00,
but
some
things
caused
it
to
get
pushed
was
the
documentation
specifically
around
creating
clear
separation
between
user
content,
creator
contents
or
plugin
authors
and
core
content.
So,
like
you
want
to
make
changes
directly
to
opt-in
core
right
now,
there
is
not
a
great
distinction
between
Noctem
dev
repo,
that's
in
the
markdown
and
the
different
hacking
guides
and
contributing
guides.
It's
a
little
muddy
and
confusing.
B
So
you
want
to
create
a
clear
guide
for
how
to
get
started.
Writing
plugins
that
will
exist
on
octant
dev.
It
will
be
a
what
people
are
used
to
when
they
go
in.
To
start
writing
new
software
for
for
a
platform,
it
will
be
here's
how
you
copy
and
paste
these
things
into
your
environment,
down
like
clone
this
repo,
which
will
be
our
octants
sample,
plugin
repo
and
then
run
these
commands,
and
you
will
have
a
working
plugin
that
you
can
start
hacking
on
right
now,
that's
kind
of
not
how
it
goes
right.
Now.
B
It's
kind
of
like
people
come
into
the
octave
channel
and
go
I'm
working
on
plugins
and
I
found
this
over
here
and
this
over
here.
Am
I
doing
the
right
thing
and
we
want
to
remove
that
that
barrier.
That's
there.
A
couple
folks
have
asked
for
this
as
well.
Just
even
folks
who
are
already
writing.
Writing
plugins
will
find
it
useful
because
when
they
don't
write
a
plug-in
for
a
while
and
then
come
back
and
want
to
do
a
new
one,
they
don't
have
to
relearn
all
of
these
kind
of
hidden
steps.
B
So
we
want
to
get
that
in
place
and
then
we
also
want
to
make
a
clear
user
guide
for
getting
started
just
for
users
of
octants,
so
I'm
a
developer
and
I
am
not
intending
to
write
any
custom.
Plugins
I
just
want
to
use
octant
against
my
dev
cluster
and
use
it
to
make
my
life
better
and
and
help
me
ease
me.
Writing
my
software.
B
That's
going
to
run
in
clusters
so
right
now,
there's
no
there's,
there's
some
video
demos
and
a
couple
blog
posts,
but
again
that
information
is
kind
of
spread
across
multiple,
multiple
media.
So
we
want
to
get
a
nice
focused,
clear,
getting
started,
guide
up
on
octant
octave
for
folks
that
are
new
to
octant
and
just
want
to
get
it
running
and
using
it.
B
Then
that's
I
owe
this
one
other
thing
and
Sam
has
a
question
about
this.
I
think
I
assume
it's
from
Sam.
It
might
have
been
from
somebody
else,
but
around
plug
in
documentation
and
documenting
the
components
themselves.
This
is
part
of
that.
The
line
item
where
we're
wanting
to
create
like
creator,
content
for
plugins.
B
We
we
want
octant
dev
to
be
the
source
of
truth
for
plugin
authors,
so
you
will
go
to
octant
at
dev.
Then
you
will
click
plugins
and
then
there'll
be
the
getting
started,
which
is
what
I
just
described
and
then
there'll
be
the
you
know:
API
and
you'll
click
API,
and
what
you'll
get
is
a
list
of
all
of
the
important
API
sort.
B
Plugin
authors
we're
gonna
kind
of
get
rid
of
right
now,
when
you
start
to
drill
into
plugins
you're,
getting
a
mix
of
like
internal
API
is
an
external
API
is
and
it
can
be
confusing
about
which
ones
you
need
to
care
about.
So
we're
going
to
create
a
nice
interface
for
that,
so
that
you
can
clearly
see
here.
The
API
is
I
care
about
as
a
plugin
out
there
and
I
can
go
read
about
them.
I
could
find
out
all
these
components.
B
B
A
B
So
the
only
thing
that
we
know
on
Sam
and
myself
had
a
quick
conversation
and
kind
of
agreed
I
think
we
agreed
I'm
gonna
assume
we
did.
We
agreed
that
the
everything
that's
in
sight
should
be
a
user
and
creator
content
and
the
only
thing
that
should
be
in
the
core
repo
in
markdown
files
on
the
query.
People
is
I
want
to
contribute
to
octant
core
I
I
need
to
know
the
architecture
of
octants
or
I
need
to
know
how
to
create
a
brand
new
component
from
scratch,
or
things
like
that,
though.
B
That's
what's
gonna
live
in
the
repo
and
I
and
we're
not
gonna
push
that
stuff
out
to
octant
dev,
mainly
because
I
think
it
can.
It
can
kind
of
create
a
little
bit
of
confusion
between
plugin
authors
and
core
contributors
and
I
want
to
create
a
distinction
there,
because
a
lot
of
our
plugin
authors,
I
was
saying
this
to
to
Sam
and
Milan.
They
don't
want
to
be
core
contributors.
B
A
B
All
right,
moving
on
to
the
next
item
of
focus,
we're
gonna
be
revisiting
the
well
not
revisiting
really
starting
on
the
electron
application.
So
this
has
been
kind
of
a
long-running.
It
has
kind
of
having
a
long
tail
on
it
because
it
was
depending
on
some
angular
9
stuff,
and
then
that
depended
on
clarity
three
and
then
so
it
just
kept
getting
pushed
and
pushed.
B
There's
an
epoch
that
tracks
all
of
them
under
our
application
epoch.
So,
if
you're
curious
about
what
this
kind
of
looks
like
from
a
issue
and
and
swimlane
perspective,
I
encourage
you
to
check
out
our
our
Zen
hub,
which
you
can
find
linked
in
the
repo
the
main
readme
for
the
for
the
repo
and
I
think
right
there
on
the
community
page
yeah.
B
And
that's
this
there's
not
a
whole
like,
like
that's
kind
of
it
around
the
electron
application.
There.
Isn't
it
isn't
a
a,
but
most
people
using
this
will
just
find
it
easier
because
they
won't
no
longer
have
to
run
things
from
the
command-line
and
they'll.
Just
you
know
double
especially
Windows
users
they'll
be
double
click,
the
executable
right
now,
if
you
double
click
octant
in
Windows,
it
says
this
is
a
command
line.
App!
That's
it
it's
all.
B
B
There
are
some
new
components
and
I
want
to
call
this
one
out,
because
there
was
also
a
question
asked
about
it,
but
being
able
to
inject
your
own
HTML
Javascript
assets
directly
into
the
the
page
via
a
component
that
we
definitely
want
to
have
that
before
we
do
a
version
one
of
the
API
multiple
people
have
asked
for
it,
we're
still
working
on
kind
of
figuring
out
the
best
way
to
do
it
at
least
the
in
the
introversion
one
we
don't
want
to.
We
don't
want
to.
B
B
The
expectation
that
that
is
going
to
work,
considering
we're
using
angular
is
probably
low
and,
and
so
so
we'll
we'll
be
sure
to
document
some
things
as
we
as
we
go
down
the
road
of
getting
like
a
web
component
in
place
and
then
the
documentation
around
plugins
which,
like
I,
talked
about
previously.
We
want
to
get
all
of
that
in
place
so
that
it's
easy
for
folks
to
discover
the
different
components
and
the
important
API
is
for
writing
a
plug.
A
Just
a
question,
so
this
is
for
just
so
everyone
understands,
so
the
electron
application,
the
documentation
of
the
plug-in
API.
Your
say
this
is
gonna,
be
the
majority
of
the
the
next
body
of
work.
Where
do
you
you
have
like
a
rough
timeline
of
when
we
can
see
the
first
version
of
the
electron
app?
You
have
a
rough
timeline
of
when
the
documentation
will
be
available
properly
on
Aachen
dev,
just
things
like
that.
B
B
B
For
the
first
time
the
currently
we
ship
binary
releases
of
octant
and
when
we
do
that
we
cut
a
whole
new
release
and
we
increment
the
version
number
and
we
move
forward
like
that.
So
as
we
move
towards
having
the
electron
application,
it
will
have
the
ability
to
self
update.
So
there
will
still
be
releases
of
octant
and
they'll
still
be
version
for
our
sake
and
the
sake
of
bug,
tracking
and
porting
issues,
and
things
like
that.
B
But
the
important
version
number
for
octant
will
become
the
plug-in
API
that'll,
be
the
that
will
be
the
version
that
will
of
octant.
That
will
actually
become
what
people
care
about
from
a
creator
and
dev
standpoint,
the
user
from
the
user
standpoint
you'll
care
about
it
as
well,
because
if
you
have,
if
you
want
to
get
a
plug-in
and
it
and
we're
happened
to
be
on
version,
plug-in
version
3
and
your
plug-in
is
version
1,
then
the
they'll
be
need
to
be
an
update,
probably
at
least
to
get
it
to
2
and
today
so
well.
B
B
Gonna
look
like
is
that
the
plug-in
API
version
will
be
the
important
version,
and-
and
this
also
becomes
the
case
when
further
down
the
road
later
in
this
calendar
year,
when
we
start
to
do
the
the
planning
and
the
thinking
and
the
implementation
around
octant
in
cluster
being
that
it
will
be
a
plain
web
app
running
in
cluster
again,
the
version
itself
won't
really
be.
The
important
thing.
B
B
We
know
that's
important,
we
want
to
do
it,
we
want
to
do
it
well,
we
want
to
do
it
in
a
smart
way
so
that
you
have
type-ahead
so
that
you
have-
and
you
know,
information
coming
from
the
API
server
to
inform
you
on
your
custom
resources
and
your
config
Maps
things
like
that
resource
for
your
workload
viewer,
we
kind
of
want
to
tighten
up
how
those
interact
with
each
other
we're
moving.
We
want
to
be
moving
towards
making
the
workload
viewer,
resource,
fear
and
object
status,
kind
of
this.
B
They
exist,
they're,
not
they're,
not
really
cohesive,
they're
not
put
together
in
a
way
that
they
were
they're
all
working
together.
An
object
status
in
particular
is
really
lacking
in
detail
and
a
useful
information
that
are
that
can
lead
us
to
actionable
items
and
the
the
reason
we
want
to
move
towards.
Making
these
things
work
together,
and
especially
getting
our
object,
status.
Updated
is
because,
once
the
resource
here
and
workload
viewer
are
are
kind
of
a
joint
tool
for
navigating
a
workload
within
a
namespace.
An
object
status
has
actual
items.
B
Now
we
can
get
into
your
name
like
this
thing
is
looking
for
this
config
map.
It's
called
foo.
The
only
config
maps
that
exist
in
this
namespace
are
called
bar.
Do
you
want
to
edit
this
resource
to
use
config
map
bar?
Yes,
right
like
being
able
to
do
something
like
that
is
where
we
want
octant
to
go
and
in
the
direction
we're
heading.
So
that
is
why
this
kind
of
next
cat,
this
next
subcategory,
is
focused
around
that
interaction
with
workloads
in
the
cluster
workloads
in
your
namespace.
B
B
B
And
then
future
is
octant
and
cluster
I'm
just
gonna
leave
it
at
that.
Yes,
we're
gonna
be
running
we're
going
to
be
working
towards
the
idea
of
getting
octant
in
cluster.
It
has
been
something
that
has
been
requested
and
requested.
We
have
intentionally
not
pursued
it
because
we
wanted
to
focus
on
getting
some
of
the
other
internal
features
and
interfaces
within
octant
up
to
a
certain
state
before
we
went
back
to
revisit
in
cluster.
So
this
is.
B
B
Imagine
some
of
that
planning
will
be
happening,
not
I
admit
that
planning
will
be
happening
through
the
proposal
process
that
we
have
for
octant
and
that
also
the
brainstorming
sessions
will
be
public
and
happening
depending
on
like
the
length
of
community
meetings
ordering
I
have
octant
office
hours
during
those
types
of
sessions.
So
all
of
the
planning
around
in
cluster
will
be
documented,
and
then
we
will
be
doing
a
formal
proposal
for
the
initial
implementation
of
octant
and
cluster.
There
is
already
a
branch
in
the
upstream
for
octant
in
cluster.
B
B
D
D
B
That's
that's
as
far
as
it
currently
is
so,
and
I
wanted
to
just
retouch
on
so
I've
had
some
folks
take
advantage
of
the
octant
office
hours
and
it's
been
it's
been
really
great.
So
I
just
wanted
to
remind
everyone
that
on
Thursday,
so
in
this
case
tomorrow,
I
do
acht
and
office
hours
between
1:00
p.m.
and
5:00
p.m.
Eastern,
Daylight,
Time
and
they're
open
to
anybody.
You
just
you
go,
you
click
reserve
a
spot,
and
we
can.
B
We
can
talk
about
anything
octant
related
that
you
want
so
folks
have
used
it
for
plugin
stuff
and
we're
I.
Think
we're
talking
to
some
I'm
talking
to
somebody
tomorrow
for
I.
Don't
know,
I'd
have
to
actually
look
I,
don't
I
just
know
I'm
talking
to
two
people
tomorrow,
so
it's
whatever
they
want.
That's
what
we're
talking
about,
and
so
that's
it
for
the
the
main
bulk
of
the
community.
B
I
did
want
to
say
another
another
thanks
to
to
Jordan
Jensen,
who
has
been
a
member
of
the
community
and
contributing
to
octant
from
very
early
on
like
since,
since
we
open
sourced
it
I
just
wanna
say
thank
you
again.
He
he
might
not
be
around
as
much
so,
if
that's
the
case,
you
know
I
just
wanted
to
say
a
big
thanks
to
you
to
him
for
all
of
all
the
contributions
and
being
a
part
of
the
community
I.
D
Can
you
see
my
screen
yep
yep,
all
right,
so
we've
done
quite
a
bit
of
work
on
reworking
the
navigation
and
as
you
now,
the
current
navigation
is
basically
tree
view
that
has
a
lot
of
problems.
There's
a
it's
a
pretty
complex
issue.
We
have
a
lot
of
items
and
the
way
a
tree
view
handles
them.
It's
not
so
optimal.
So
we
were.
We
wanted
to
switch
over
to
what
clarity
calls
the
vertical
navigation
and
then,
during
that
work,
video
wise.
Maybe
we
need
to
divide
things
a
little
more
into
domains.
D
We
experimented
with
adding
those
domains
into
the
header
and
it
was
there
the
amazing
work
putting
those
into
two
mock-ups
and
we
played
with
those
for
a
while,
but
then
at
the
end
we
kind
of
thought.
Maybe
this
vertical
now
should
be
sufficient,
but
we
had
some
problems
with
it,
as
you
can
see,
there's
still
quite
a
few
groups
and
some
of
those.
D
So,
for
example,
if
I
go
to
services
and
then
you
go
to
work
holes,
there's
a
bunch
of
things
open,
but
we
thought
maybe
well
quite
the
usual
thing
is:
if
you
expand
one
thing,
maybe
you
can
co-op's
everything
else,
which
will
say
it's
quite
a
bit
to
article
space
and
their
question
was
so
that
by
default
is
not
supported
by
clarity.
The
library
we
are
using
so
I
did
a
little
bit
of
work
to
to
just
to
test.
D
If
that's
possible,
with
clarity
and
as
you
can
see,
it
is,
and
it
does
work
pretty
well,
it
saves
a
lot
of
vertical
space
and
in
the
same
time
you
can
the
animations
that
I
think
clarity
is
handling
the
animations
pretty
well.
Sometimes
those
are
not
so
optimal.
If
you
have
one
things,
go
up,
seeing
the
other
one
expanding,
but
I
think
the
clarity
is
handling
that
well,
so
that
was
pretty
comforting
to.
You
know
be
able
to
do
that.
But
then
the
other
thing
is
there's.
D
This
thing
is
still
using
a
lot
of
horizontal
space,
but
then,
if
weeks
and
that,
if
he
collapse
it
will
save
all
that.
The
problem
here
is
that
some
of
those
icons
are
not
that
descriptive
and
then
I
played
with
that
a
little
bit
and
I
tried
using
tooltips
for
that.
Although
I
hate,
quality,
tooltips
I,
think
that's
a
little
helpful
and
this
saves
a
lot
of
space
and
the
thing
is,
if
you
click
on
one
of
these,
it
just
opens
that
flyout.
D
As
you
can
see
there,
there's
not
much
going
on
there,
so
it
still
saves
a
lot
of
space.
So
so
this
is
kind
of
where
we
are
right
now,
there's
still
a
bunch
of
issues
related
to
the
plugins,
as
you
can
see,
I
have
one
plug-in
here,
but
if
there's
a
bunch
of
plugins,
this
may
become
quite
bigger
and
also
the
custom
resources,
but
overall
I
think
this
is.
This
is
a
step
in
the
right
direction,
with
a
particular
obligation
and
expanding
collapsing.
D
We
can
even
remember
that
states
you
can
come
back
in
and
especially
as
rainless
sync
that
you're
gonna
start
using
the
results
viewer
more
for
navigation.
So
in
that
case
maybe
navigation
like
there
should
be
sufficient
enough
for
the
you
know,
just
didn't
behind
there
of
the
navigation.
So,
for
example,
for
some
things
that
you
don't
access
so
frequently,
you
can
always
go
back
here
and
try
to
find
out
so
so
that
I
don't
want
to
keep
everybody
so
long
here,
that's
pretty
much
all
I
had.
C
C
D
D
Obviously
it's
it's
pretty
hard
to
show
that
in
the
co-op
state
and
the
way
there
was
implemented
initially,
it
was
showing
up
on
me
in
the
expanded
state
that
here
the
top,
but
then
you
get
in
the
problem
and
those
things
down
the
line.
If
you
collapse,
as
you
can
see
now
those
icons,
if
you
watch
them
as
they
collapse,
they
expand,
they
stay
at
the
same
place
vertically.
B
A
A
E
In
order
to
poke
things
through
to
the
UI,
you
have
to
go
through
the
octant
wrapper
and
that's
not
always
conducive
to
visualization
in
a
way
that
would
be
much
easier
if
we
just
had
access
to
the
underlying
components
that
are
I'm,
I'm,
assuming
and
probably
incorrectly.
That
under
the
under
all
of
this
doctrine
is,
is
rendering
HTML
or
JavaScript
and
then
passing
it
to
the
browser
which
is
rendered
for
the
user.
E
B
B
So,
yes,
we
want
to
support
this
ability
to
allow
plugins
to
send
plain,
HTML
and
JavaScript
to
the
front
end
and
then
handle
that
you
know
just
render
that
as
a
straight,
you
know
passed
through
the
way
octant
currently
works
is
we
take
a
JSON
object
and
we
encapsulated
into
some
metadata
and
then
some
some
content,
and
then
we
send
that
into
the
front
end,
which
is
our
angular
application
and
then
that
JSON
content
you
use
it.
We
take
the
metadata
out
of
it
to
then
map
it
to
a
component.
B
So
the
list
component
or
you
know
any
of
the
the
status
component,
any
of
the
objects
that
you
see
cards
and
stuff
like
that.
Those
are
all
parsed
from
metadata
to
map
it
to
the
angular
component
from
the
backend
component
and
then
there's
a
usually
some
type
of
data
or
content
blob
that
is
then
injected
into
that
component
before
it
is
to
render
it
out
to
the
screen-
or
maybe
it's
maybe
it's
rendered
to
the
screen,
but
angular
handles
the
rendering
of
it
once
the
the
content
that
the
component
contains
has
been
updated.
B
Or
some
way
of
saying
like
here
is
the
the
plain
HTML
Javascript
that
we
want
to
inject
into
the
view
all
of
our
plug-in
and
then
that
would
get
passed
over
the
wire.
The
component
would
get
rendered
the
angular
and
then
the
content,
the
JavaScript
and
HTML
would
be
injected
into
the
page,
so
that
that
is
the
process
that
achtung
uses
to
put
stuff
to
the
front-end.
There's.
Actually,
no
HTML
Javascript
generation
happening
on
the
backend
at
all.
B
B
C
I
was
yes,
so
this
is
with
regards
to
our
Docs
push
for
this
particular
release
and
I'm,
starting
to
work
on
doing
some
auto-generated
documentation
for
our
components.
I've
started
on
this
a
while
back,
but
then
I
dropped
it
4.11
issues,
so
I'm
picking
back
up
into
this,
and
so
this
is
a
neat
little
tool
that
can
just
use
doc
strings.
You
know
generate
everything
we
want.
C
The
thing
I
don't
like
about
this
is
that
it
breaks
continuity
with
the
octave
doc
dev
website,
and
it
might
use
too
much
angular
semantics,
whereas
most
people
might
just
simply
be
interested
in
the
component
itself,
so
I
just
wanted
to
throw
it
in
a
community
meeting
to
see
how
we
feel
about
something
like
this
and
whether
or
not
having
extra
information
here,
that's
more
pertinent
to
angular
is
going
to
be
confusing
or
whether
or
not
this.
We
should
just
use
a
tool
like
this
and
just
save
a
bunch
of
time.
B
B
A
So
yeah,
if
you
so
Sam,
you
said
that
this
would
break
compatibility
with
da
dev,
so
it's
salutely
internally
possible
to
have
this
be
under
different
sub
domain,
or
something
like
that,
so
it
could
be
dev,
Docs
or
angular
Doc's
docked
it
there
or
whatever.
You
want
so
I'm
more
than
happy
to
help
you
set
this
up.
If
this
helps
you
in
documenting
how
to
well
how
to
build
octant
and
the
different
components
that
you
use
absolutely.