►
Description
January 24th, 2022.
The links mentioned in the video:
- The Issue: https://gitlab.com/gitlab-org/gitlab/-/issues/349635
- The PoC #1: https://gitlab.com/gitlab-org/gitlab/-/merge_requests/78579
- The PoC #2: https://gitlab.com/gitlab-org/gitlab/-/merge_requests/79013
A
Hello,
everyone
we
are
here
in
with
the
create
editor
group
to
talk
about
content,
editor
integration
into
the
editing
interfaces
of
the
product,
and
that's
going
to
be
a
very
short
introduction.
That's
that's
what
we
are
going
to
talk
about
today
in
the
agenda
linked
to
this
meeting.
There
are
links
in
the
in
the
in
the
agenda
for
this
meeting,
there's
a
link
to
the
issue
that
sparked
this
discussion,
and
there
are
two
links
to
two
pocs
and
just
to
make
it
clear.
A
These
pocs
do
not
compete
with
each
other.
It's
just
like
approaching
exactly
the
same
thing
from
different
angles,
so
that
we
could
have
a
fuller
picture
of
how
things
can
be
glued
together.
But
before
we
proceed,
I
would
like
probably
eric
to
sum
up:
what
is
what
is
the
end
goal?
What
what
are
we
supposed
to
implement
like,
and
I'm
asking
this
after
two
pocs
now
right?
So
what
and
why?
B
Rewind
back
two
years
when
I
started
on
the
static
site
editor
and
a
lot
of
the
research,
there
was
around
non-developer
personas,
who
would
be
intimidated
by
the
repository
structure
intimidated
by
the
web
ide
itself
intimidated
by
markdown,
and
those
are
all
three
of
the
top
barriers
to
collaboration
and
contribution.
So,
with
the
winding
down
of
the
static
site
editor,
I
was
really
hoping
that
we
could
find
a
way
to
bring
people
into
the
web
ide
or
the
web
editor
or
somewhere
in
the
repository
view.
A
A
C
Poc
number
one,
so
this
poc
is
focused
on
pretty
much
integrating
the
the
continuator
into
the
web
ide.
The
idea
is
that
when
you-
oh
my
god,
I
don't
know-
I
don't
even
know
if
I
have
to
run
an
example.
No,
I'm
not
ready
for
that.
There's
a
youtube
video.
I
I
think
that
I
can
play
it.
Do
you
think
that
that
would
work
like?
So
you
can
see
how
the
poc
works.
C
B
E
C
That's
right,
so
the
contaminator
is
just
like
applying
its
formatting
preferences
for
markdown,
because
we
don't
have
a
good
mechanism
for
to
preserve.
They
don't
change
document
the
change,
don't
change
part
of
the
document.
So
why
did
I
create
this
proof
of
concept
so
denise
and
I
were
talking
about
what?
What
is
the
the
best
technical
direction
to
integrate
the
content
editor
in
the
web?
Ide?
C
C
A
Cool,
thank
you
very
much.
Okay,
I've.
I've
put
a
couple
of
notes
in
the
agenda
so,
first
of
all
this
is
this
is
really
cool
demo
and
I'm
I'm
I
I
will
be
honest.
I
haven't.
I
haven't
expected
this
to
be
that
easy
to
implement
content
data
into
the
web
id
and
I'm
I'm
super
super
happy
to
see
that
it's.
It
is
actually
that
simple,
so
that
that
was
that
is
really
impressive
work
enrique.
Thank
you.
However,
I
have
a
question.
A
A
C
C
C
E
I
I
just
to
piggyback
on
it
like
there
is.
We
do
want
to
make
sure
that
the
repo
editor,
if
we're
treating
vuex
as
a
single
source
of
truth,
we
need
to
make
sure
view
x,
is
the
single
source
of
truth,
and
something
would
be
off
if
the
repo
editor
is
doing
more
than
it
should.
So,
that's
something
to
look
at
if
there's
logic
happening
in
the
repo
editor
which
we
might
need
to
see
if
we
need
to
promote
up
in
the
view
x,
store
or
something
like
that,.
C
The
proof
of
concept
I
I
I
had
like
I-
I
could
rely
on
those
vox
actions
to
do
things
like
hey
this
dispatch,
this
action
to
to
change
the
the
the
file
state
and
then,
like
everything
else
around
in
the
web,
id
was
reacting
to
those
stage
changes.
So
I
think
that,
from
from
that
point
of
view,
the
the
separation
is,
it's
working.
It's
working
all
right.
E
E
Sorry,
the
point
that
I
was
saying
here
was:
if,
if
you
look
at
the
repo
editor,
like
you
see,
there's
a
whole
bunch
of
file
watchers
and
the
biggest
concern
would
be
if
one
of
those
file
watchers
is
actually
critical
to
like.
Based
on
this
state
change,
we
call
this
ux
action
and
none
of
it
really
has
to
do
with
repo
editor.
It's
really
should
probably
just
live
separately
in
its
own,
like
when
we
set
up
the
store
it's
worth
going
through
is.
If
we
want
this
to
be
separate
from
repo
editor
does.
E
Is
there
something
that
the
reaper
editor
is
doing
that
you
know
maybe
belongs
to
be
promoted
up
or
something
like
that.
I
I
agree
100,
that
yeah
the
components
we
should
be
able
to
you
know,
mix
and
match
components
as
needed,
because
ux
needs
to
be
that
single
source
of
truth,
but
unfortunately,
the
web
id
we've
done
a
number
of
cases
where
sometimes
components
are
doing
business
critical
logic
in
a
really
tightly
coupled
way-
and
I
don't
know-
if
that's
the
case
here
in
the
repo
editor
or
not.
F
Yeah,
so
I
just
wanted
to
add
that
that
we
already
have
a
couple
of
viewers
that
react
to
the
state
in
ux
right
now.
They
don't
really
edit
the
state
but
later
on.
If
you
wanted
to
make
them
edit.
The
state
like
if
you
wanted
to
edit
an
image,
let's
say
change
the
dimensions
of
an
image
or
something
like
that.
That
would
still
not
be
using
the
the
content
editor
or
the
associator.
G
A
Like
we,
I
think
we
can
all
agree
that
this
has
to
be
driven
by
user
preference,
where
user
decides
for
themselves
whether
they
want
to
to
use
to
edit
markdown
as
the
code
or
as
the
wizard.
The
only
thing
that
I'm
missing
is
the
switch
between
code
and
and
the
wizardweak.
That
would
be
super
cool.
That.
A
B
Anything
not
really
a
question,
but
just
to
reinforce
what
paul
said,
and
I
know
enrique
mentioned
that
would
be.
The
next
step
is
to
explore
ux
around
switching
between
these,
but
that's
absolutely
what
we
want.
We
want
to
be
able
to
in
the
same
session
you
shouldn't
have
to
decide
one
or
the
other
toggle
back
and
forth.
B
A
Exactly
exactly
my
thoughts
like
I,
I
really
like
writing
markdown
as
a
code,
but
when
it
comes
to
tables
man,
I've
tried
it
with
the
content
editor.
I
don't
want
to
go
back
to
code
like
the
tables,
adding
tables
in
the
content.
Editor
is
so
much
so
much
simpler.
That's
like
well,
I'm
switching
to
container
to
add
my
table
not.
B
A
Exactly
right,
yes,
so
this
is.
This
is
a
very
important
point
that
we
have
to
be
able
to
switch
between
the
editors,
not
only
from
the
preference
panel,
but
on
the
go
technically
okay,
I
have
finished
my
poc
only
today,
so
unfortunately
I
couldn't
provide
this
link
earlier.
I'm
I'm
very
sorry
for
that.
A
A
Moreover,
I
was
I
was
by
design.
I
was
thinking
about
providing
exactly
the
same.
I
want
to
provide
the
same
editing
experience,
no
matter
where
we
are
editing
the
marginal
file,
be
it
web
id,
be
it
single
file
later
be
snippet,
be
anything
where
we
add
it
where
we
can
edit
a
margin
file,
and
I
will
be
honest-
I,
as
I
said,
I
wasn't
very
impressed
with
what
enrique
did
so.
My
poc
will
be
heavily
based
on
what
he
did.
I'm
sorry.
A
A
The
commits
are
split
like
you
will
find
the
content,
editor
extension
in
one
commit
and
then
integration
for
the
blobs
snippets
and
web
id
in
separate
commits,
so
that
we
could
go
through
those,
so
the
demo
time
I'll
start
with
the
let's,
let's
start
with
web
id,
since
we
were
at
the
web
id.
So
I'm
on
the
markdown
file
right
away.
A
A
A
And
like
do
some
emoji
or
something
like
this,
now,
keep
in
mind,
look
look
at
this.
First
of
all,
we
have
the
button
to
switch
back
to
the
code,
so
we
switch
back
to
the
code,
the
content
we
have
at
it
is
here
we
can
switch
back
to
the
wizardweak
and
again,
as
enrique
demonstrated,
the
the
changes
are
going
to
be
here.
A
We
can
preview
if
we
want
and
then
like
technically
editing
in
wysiwyg
is
the
full
step
forward
for
for
the
visual
editing,
so
things
things
are
preserved,
things
get
get
saved
properly
and
in
this
particular
case,
we,
the
communication
between
the
content,
editor
and
the
source.
Editor
happens
with
with
the
properties
and
events
as
as
it
should
be.
A
The
only
thing
that
I
I
changed
was
I
wrapped
the
content,
the
original
content
editor
into
this
new
component,
that
is,
that
is
part
of
the
extension
in
order
to
be
able
to
set
up
the
slots
for
the
toolbar
of
the
condensator,
so
that
I
could
pass
in
the
button
to
switch
back
to
the
code,
and
I
have
significantly
comparing
to
the
first
poc
I
have
complete.
I
have
significantly
simplified
the
communication,
because
the
difference
here
is
that
I
do
not
communicate
changes
from
content
editor
to
the
source
header
on
every
change.
A
Technically,
once
we
make
one
change,
I
raise
the
flag.
Yes,
the
changes
are
there
and
then
that's
that's
pretty
much
it.
We
swap
the
con.
We
swap
the
content
when
we
switch
the
change
of
the
switch
the
editor
or
when
the
source
editor
explicitly
asks.
Content
editor
to
return
the
content,
it's
when,
for
example,
we
save
the
document
or
something
like
this.
A
At
any
point
in
time,
and
while
working
with
this,
it
helped
me
to
to
catch
a
couple
of
bugs
in
source
editor
and
shape
up
source
editor
as
well.
So
it
was
the
win-win
situation
here.
So
this
is
how
it
works
in
web
id
right.
So
it's
pretty
pretty
similar
to
how
it
works
in
in
the
fur,
in
the
first
poc.
But,
as
I
said,
implementing
this
as
the
as
an
extension
to
the
source,
header
allows
us
to
introduce
this
functionality
anywhere,
where
we
use
source
editor
and,
for
example,
the
single
source
editor.
A
A
Set
up
in
the
preferences
as
well,
if
I
want
always
open
my
markdown
files
with
the
wysiwyg
editor,
that
would
save
me
a
lot
of
clicks
sort
of
so
and
that
exactly
matches
the
the
scenario
where
we
talk
about
non-developer
users,
who
will
who
are
primarily
working
with
the
markdown
files,
but
okay,
we
in
this
case
it's
exactly
the
same
thing.
This
is
this
is
the
in
my
case.
In
my
my
opinion,
this
is
the
beauty
of
of
this
solution.
It's
exactly
this.
A
A
When
we
speak
about
the
snippets,
this
is
where,
where
I
think
the
beauty
of
of
this
particular
integration
comes
into
play
is,
if
I
have
we,
we
allow
up
to
10
snippets
in
the
multifile
snippet
scenario.
If
we
have
10
10
markdown
files,
it
will
cost
nothing
to
the
users
to
to
edit
the
to
to
lo,
to
start
this
page
with
the
10
source
editors
that
might
are
possible
to
switch
to
condenser.
A
I'm
not
sure
how
this
can
be.
This
is
going
to
be
implemented
with
the
content
data,
but
I
suspect
we
would
need
to
have
10
instances
of
the
content
editor
on
this
page.
I
don't
know
whether
it
will
affect
performance
or
not,
but
this
is
this
is
really
beyond
this.
This
particular
implementation
we
we
can
come
up
to
this
later,
but
in
the
snippets
exactly
the
same
thing,
just
exactly
the
same
functionality
in
all
the
instances
and
whenever,
wherever
we
can
use
source
editor
we
can
implement.
A
We
can
extend
the
experience
by
providing
this
with
weak
implementation
and
when
it
comes
to
the
particular
implementation.
So,
let's
just
take
a
look
at
how
how
simple
it
is
really
for,
for
example,
let's
take-
I
don't
know,
let's
take
web
id
to
compare
apples
to
apples,
so
all
it
takes
to
implement
this
in
web
id.
Is
this
so
and
most
like,
and
it's
most
of
it
is
just
moving
the
mechanism
of
setting
up
the
extensions
into
the
separate
async
function.
Otherwise
it's
really
exactly
the
same
web
id
yeah.
So
that's,
that's!
A
That's
it.
So
my
main
rational
behind
this
is
to
provide
exactly
the
same
editing
experience,
no
matter
what
part
of
the
project
you're
at
to
come
to
minimize,
if
not
eliminate
the
complexities
related
to
the
integration
part,
but
as
we
have
seen
in
the
first
poc,
it
doesn't
take
much
to
implement,
implement
this
in
web
id.
The
the
thing
is
that,
for
example,
single
file
editor.
It's
still
not
view
application,
it's
still
rails
plus
javascript
applications.
A
So
then
we
would
need
to
do
something
it's
a
bit
more
for
that,
but
not
too
much.
I
guess
for
the
first
poc.
So
really
it
boils
down
to
not
comparing
to
pocs
but
to
thinking
about
how
we
want
to
use
the
things
and
how
we
want
to
architect
the
things.
So
it's
really
to
me,
it
boils
down
to
the
architecture
decision
and
I'm
going
to
stop
sharing
my
screen
now
and
I'm
ready
for
for
the
questions.
E
I
I
left
a
comment,
but
I'm
diving
into
it
and
I
realized
my
comment
is
slightly
inaccurate
but
still
touches
on.
I
think
one
of
the
the
interesting
side
effects
of
doing
this
through
the
source,
editor
extension,
so
it
originally
looks
like
we're
going
to
be
mounting
a
view.
App
of
content
editor
inside
the
web
id
view
app,
but
I
see
that
we
actually
created
this
like
external
mounting
point
and
then
had
flags
to
that
like
through
css.
E
A
A
Have
you
yet
and
to
be
honest
like
if
we
are
talking,
if
we're
talking
about
implementing
this
with
view
components,
probably
the
first
poc
will
be
simpler,
because
the
logic
of
the
current
extension
is
based
on
the
premises
that
everything
is
very
well
scoped,
and
I
want
to
be
to
make
sure
that
when
we
move
things
around,
they
will
keep
working
exactly
as
they
used
to.
So
I
don't
need
to
change
the
implementation,
don't
need
to
change
the
integration
part.
It's
it's
very
well,
scoped!
It's
in
my
opinion
having
having
it
well.
A
A
C
So
I
think
that
at
the
end,
this
is
a
a
conversation
about
the
trade-off
that
we
get
from
the
portability
of
creating
a
single
source,
editor
extension
and
then
like.
We
can
just
like
use
this
infrastructure
that
they
consider
the
source
editor
provides
at
the
load
extension
everywhere
versus
following
a
developer
approach.
That
is
that
is
like
that.
That
is
that
we
are
more
familiar
by
using
the
the
view
framework.
C
What
are
we,
what
what
we
would
be
sacrificing
like?
We
were
talking
like
when
we
implemented
the
a
demo
how
how
we
could
implement
the
the
markdown
live
preview.
So
we
tried
to
do
this
on
just
using
the
view
framework
and
it's
like.
Okay,
we
are
following
patterns
that
all
of
the
gitlab
developers
are
familiar
with
it's
easier
to
maintain
because,
like
vr3
provides
most
of
the
infrastructure
to
do
a
synchronous,
loading
of
components,
we
don't
have
to
handle
it
on
directly.
We
don't.
C
We
don't
have
to
deal
with
dumb
nodes.
We
don't
have
to
free
up
resources,
so
it's
pretty
much
the
the
same
conversation
and
I
think
that
it
both
it
boils
down
to
that
like
if,
from
an
architectural
point
of
view,
we
want
to
stick
with
the
the
are
the
the
big
and
the
well
the
wide
architectural
decisions
that
all
of
the
other
groups
in
github
are
following,
or
we
want
to
introduce
this
new
way
of,
like
you
know
like
integrating
ui
components
in
the
in
the
application.
A
These
are
very
good
points.
First
of
all
about
the
async
loading
components.
The
components
are
as
async
asynchronously
loaded
in
this
poc
as
they
are
in
the
first
one.
So
there
are,
there
is
no
change
in
that,
so
the
components
are,
as
I
think,
as
they
can
possibly
be.
Moreover,
the
the
editor
here
is
not
mounted
unless
we
user
explicitly
requests
this
this
component.
A
The
point
is
that
not
all
the
users
of
the
of
the
editors
that
might
want
this
to
be
implemented
in
their
parts
of
the
application
are
a
view
view
ready,
saying
that.
Well,
if
you
want
to
use
wiz
week
editor,
you
have
to
refactor
to
refactor
to
view
that's
that's
a
valid
point,
but
it's
it's
like
bringing
the
problem
from
our
table
to
their
table.
A
A
So,
that's
again,
that's
and
when
we
were
talking
about
the
this,
this
approach
at
the
architecture
session
we're
talking
about
exactly
the
small
ui
components,
in
my
opinion,
in
this
particular
case,
for
a
packaging
purpose
for
usability
purpose.
I
think
this
is
exactly
the
justified
case,
as
I
mentioned
in
the
comment
for
in
the
in
the
issue,
but
I
might
I
might
be
wrong
here
in
my
assumptions.
H
Yeah,
so
maybe
thinking
about
this
from
a
product
perspective
like
do
we
think
it's
reasonable
to
expect
that
every
place
that
there
is,
we
use
an
editor
that
we're
going
to
want
to
always
use
both
the
content,
editor
and
the
source
editor
to
support
editing
of
either.
I
don't
know
it
seems
like
a
reasonable
assumption
and
if
that's
the
case,
maybe
that's
something
that
leads
us
towards
yeah.
B
I
think
I
mean
to
to
get
right
to
it.
Yes,
I
think
there
probably
would
be
desire
in
any
instance
of
markdown
editing
to
switch
into
this.
At
least
I
like
to
think
there
would
be.
There
might
be
some
that
are
more
inclined,
like
maybe
in
snippets
they're,
probably
going
to
get
lower
usage.
That
would
be
fantastic
to
analyze,
but
I
can't
imagine
somebody
would
be
like
I
absolutely
do
not
want
to
have
wysiwyg
available
in
this
context
right
like
so.
B
H
E
Well,
I,
for
one
want
zero
wizzywig
experiences
for
my
team,
because
it
just
makes
them
lazy,
I'm
joking!
No,
I
I
think
when
we
talk
about
reusing,
a
cohesive
thing
across
the
application,
I
think
vue
is
our
best
perspective
at
the
tool
set
of
doing
that,
and
so
it's
really
great.
We
have
a
content,
editor
component,
that
does
that
in
fact,
dennis's
poc
for
the
source,
editor
extension
reuses
that
same
component,
and
so
that's
that
is
really
great.
E
The
my
biggest
concern
with
the
source,
editor
poc
is
it's
a
it's
an
arc.
It's
a
view,
anti-pattern
and
red
flag
to
create
a
view
app
inside
of
a
view
app
so
right
now
we
have
sports
center
extensions
that
do
dom
manipulation
stuff,
but
it's
actually
creating
a
new
view.
App
inside
of
the
wider
web
id
view
app.
It
would
be
really
nice
if
the
source
editor
extensions
were
more
view.
Native
of
like
I
can
just
say
you
know,
hey.
I
want
to
here's.
E
My
service
editor
we're
doing
markdown
and
yes
sometimes
I
want
you.
I
want
you
to
use
the
content
editor
if
you
do
markdown
and
from
that
perspective,
even
though
not
everything
is
view
based,
you
know
we're
able.
We
do
have
patterns
of
pages.
That
aren't
completely
using
view.
Can
you
just
use
part
partly
view,
and
so
the
question
is:
does
that
part
just
use
the
content
editor
or
the
source
editor,
and
I
think
it'd
be
nice
to
have
just
one
component
for
the
entire
editing
experience,
but
it
has
to
be.
E
It
has
to
be
view
native
and
I
I
would
be
concerned
if
we
start
the
biggest
concern
is
if
we
spread
an
abstraction
that
is
leaky
and
flaky,
and
that's
why
I'm?
I
think
it's
help.
It's
helpful
that
we
have
content
editor
as
a
view
component.
It
feels
like
the
source.
Editor,
isn't
the
the
view
component.
It
doesn't
seem
to
play
nicely
with
the
ide,
and
I
think
that
would
be
a
prerequisite
for
doing
this.
A
A
So
it
is
the
red
flag
probably,
but
as
you
can
see
in
the
in
the
implementation,
this
view
application
bootstrapping
part
can
be
taken
out
of
the
of
the
extension
and
there
are.
There
are
technically
two
possibilities.
First,
is
we
create
two
different
extensions,
one
for
the
view
components
for
working?
In
the
view
environment
we
are
working
with
the
existing
view
of
view,
components
and
the
second
one
is
for
like
for
the
single
file
editor
where
we
we
write
it
so
that
you
application
is
bootstrapped
by
the
by
the
extension.
E
For
the
single
file
editor
like
like
why
why,
if
we
had,
why
don't
we
just
bootstrap
source
editor
if
the
source
editor
is
doing
content
editor,
like
I,
I
hear
what
you're
saying,
but
I
also
feel
like
you
know,
for
if
we're
using
view,
then
we
use
it
anywhere
up
the
component
tree.
We
don't
have
to
just
load
the
content
editor.
We
can
load
the
source
editor
as
the
view
component
if
the
source
center
vehicle.
E
My
and
that's
my
biggest
concern
and
that's
why
I
feel
like
if
we
want
to
be
able
to
switch
nicely
between
views,
I
feel
like
we
gotta.
The
source
editor
component
has
to
be
as
usable
and
be
able
to
do
as
robustly
the
same
amount
for
us
to
to
be
able
to
switch
components
and
stuff.
I
think
that's
a
that
would
be
really
nice,
and
so
my
concern
is
that
it
seems
like
the
source.
A
A
This
is
my
my
personal
opinion,
but
again
we
can
bootstrap
view
application
outside
of
the
extension.
Should
we
need
this,
we
can
tune
the
extension
so
that
it
works
with
the
existing
component
on
the
page.
The
problem
that
I
have
with
doing
the
hybrid
things
is
that
the
view
components
will
talk
to
each
other
using
view,
and
then
this
component,
with
the
with
the
source,
editor
extension,
will
will
be
speaking
different
language
kind
of
like
with
events
and
properties
right.
A
So
that's
that
that
sets
us
back
to
the
discussion
of
switching
source
header
to
be
a
view,
view
native
to
be
only
view,
but
that's
sort
of
that's
that's
another
thing.
I
guess
if
we,
if
we
really
want
this
whole
this
implementation,
to
be
view
only
done.
Probably
we
should
just
take
a
look
at
the
at
having
things
in
parallel
right.
A
I'm
source
editor
and
content
editor,
but
I
would
like
to
make
two
two
comments.
The
first
one
was
we
mentioned.
The
child
once
mentioned
wiki
and
fundamentally
editing
markdown
files
in
the
repository
and
in
wiki
are
two
different
things
like
wiki
is
100.
Markdown
repositories
are
not
repositories
are
actually
majority
of
the
files
in
the
repository
is
not
like,
depending
on
the
repository,
obviously,
but
a
majority
of
the
files
are
not
markdown
files.
A
So
that's
why
it's
important
to
to
actually
preserve
this
switch
between
source,
editor
and
content
and
content
editor
and
have
source
editor
still
to
be
to
be
able
to
to
to
orchestrate
this
process
and
what
I
like
about
this
second
approach.
The
second
poc
is
that
eric
mentioned
this.
We
don't
know
how
how
often
people
do
use.
We
would
use
wizardweak
in
the
repository
who
will
use
it
and
actually
with
this
approach.
A
It
would
allow
us
to
to
measure
this,
because
we
will
see
how
often
people
switch
to
to
content
editor.
How
often
people
store
content
editor
as
their
default
editor
for
markdown
files?
How
many?
How
often
people
open
the
files
without
switching
to
content
data?
So
it
this
this
poc
already
has
all
these
bases
for,
for
the
measurement,
I'm
pretty
sure
we
can.
A
B
We're
almost
at
time
I
I
wanted
to
make
one
or
throw
one
more
point
out
there.
While
we
consider
the
direction-
and
I
think
this
plays
into
enrique-
maybe
something
that
is
related
to
what
you
just
posted
in
chat.
But
we
have
another
conversation
later
this
week,
paul's
going
to
be
presenting
a
potential
future
where
the
web
ide
is
no
longer
using
the
source,
editor
and
therefore
might
not
be
the
best
first
target
for
this
workflow.
So
what
changes
about
our
architectural
approach?
B
What
changes
if
we
target
the
web
editor
the
single
file
editor
first
or
exclusively,
does
that
enable
us
to
take
a
different
approach
or
focus
on
different
architectural
decisions?
If
we
know
that
the
web
ide
will
not
have
the
same
architecture
so
putting
that
out
there
enrique?
I
don't
know
if
that's
even
related
to
what
you
were
saying,
but
it
sounded
like
maybe
somewhat
related,
and
I
want
you
to
get
that
point
across
before
we
wrap
so
I'll
toss
it
to
you.
C
A
B
B
Summary
of
the
two
pocs
and
the
pros
and
cons
keep
this
going.
This
isn't
a
pressing
like
get
this
done.
This
milestone
kind
of
implementation
right,
so
I
want
to
make
the
right
decisions.
I
listed
a
few
things
that
I
think
are
prerequisites
and
the
one
I'll
throw
in
there
now
just
based
on
that
last
point
is
we
need
to
confu
convert
the
single
file
editor
to
view.
B
B
It's
it's
I'm
optimistic
because
we've
already
gotten
so
far,
I
was
somewhat
afraid
it
was
just
going
to
be
like
there's
really
like
major
barriers
and
talking
between
the
two
and
or
you
know,
maybe
a
performance
bottleneck
or
something
like
that,
but
it
seems
like
these
are
very
good
architectural
discussions
that
I
that
I
know
you
will
all
resolve
and
come
to
the
best
decision.
But
it
looks
like
a
very
achievable
end
goal
in
the
near
future
and
yeah.
I'm
excited.