►
From YouTube: ☀️ GSoC CloudEvents plugin mentor meeting 2021.7.05
Description
Shruti Chaturvedi demos her latest work, discussion follows and we wrap with next steps for the week ahead.
A
Okay,
so
I
guess
maybe
I'll
show
like
a
bit
of
a
demonstration
of
the
ui
itself,
and
so
this
is
a
test
ui.
This,
I
don't
think,
is
the
ui
that
we
need
to
go
with.
There
is
a
lot
going
on
in
this
particular
ui,
but
it
was
working
for
this
system,
so
I
had
it.
You
know
designed
this
way
for
now.
Okay,
so
I
I
felt
that
you
know
there
needs
to
be
a
way
to
map
or
basically
sort
of
like
table.
A
Well,
the
the
event
that's
coming
into
what
needs
to
happen
inside
of
jenkins
right,
because,
as
we
talk
last
time
in
the
last
meeting,
akara
jeff-
and
I
we
we
were
talking
that
you
know,
building
a
job
might
not
be
the
only
event
that
we
might
want
to
trigger
inside
of
jenkins.
So
so
there
should
be
a
way
to
map
or
just
table
out
what
needs
to
happen
when
a
certain
event
is
received.
A
So
the
starting
point
I
just
thought:
okay,
I'll
just
maybe
start
with
two
or
three
events
and
a
way
to
map
out,
would
be
okay.
If,
if
so
so
right
now,
we
also
decided
to
you
know
also
filter
out
events
based
on
whether
it's
a
structured
format
or
a
binary
format.
So
this
one's
working
with
a
binary
format,
but
I'll
move
this
around
so
that
we
can.
A
We
can
ensure
that
if
it's
a
structured
format,
that's
coming
in
we'll
probably
check
in
the
the
the
type
of
the
the
media
type
and
then
we'd
go
inside
of
the
data
of
the
structured
format
and
then
extract
the
ce
type
or
you
know
the
c
type
or
maybe
the
ce
source.
But
I
just
do
feel
that
c
type
would
have
more
information
packed
inside
of
it
as
like
a
cloud
event
about
that
particular
resource
and
what
has
happened
to
that
resource
so
event
topic.
A
A
Maybe
someone
would
want
to
have
two
or
three
different
type
of
particular
cloud
events
right,
so
they
can
have
org
dot,
jenkins,
la
sierra
start
or
dodge
and
star
ci
dot,
build
something
similar
like
that
and
and
then
basically,
if
all
of
those
headers
or
there's
just
not,
I
wouldn't
say
header,
I
would
say
c
type
or
just
cloud
event,
type
or
cloud
event
source.
They
would
build
either
build
a
job.
Soccer
builder
for
job
create
a
new
job,
whatever
the
user
decides.
A
So
this
is
up
to
the
user
to
figure
out
what
do
they
want
to
trigger
inside
of
jenkins,
because
again
with
multiple
events
which
are
available
and
still
that
we,
because
we
do
not
have
a
standardized
definition
for
the
kind
of
events
and
going
back
to
the
vocabulary,
which
is
the
standardized
format
which
we
don't
have
right
now.
We
might
want
to
have
a
way
to
map,
and
I
thought
that
it's
better
to
give
users
the
ability
to
do
that.
A
So
anyone
who's
using
this
plugin
as
jenkins
as
a
thing
they
should
have
the
ability
to
configure
whatever
they
want
to
do
inside
of
jenkins
when
a
particular
event
is
received,
but
this
is
again
using
a
request
response
system.
But
this
is
something
that
I
want
to
talk
more
about
after
this
sort
of
demonstration
and
also
just
change
it
to
build.
Because
again,
it's
easier
and.
A
C
A
A
Like
yes,
based
on
the
the
c
type,
so
I
so
I'm
like
filtering
it
based
on
the
cloud
I
shouldn't
put
header
here.
This
was
just
because
I
was
so
this.
As
I
said,
this
is
like
using
a
binary
format,
so
I
just
put
headers
because
c
type
is
going
to
be
present
in
the
header,
but
it's
bring
on
the
class
event
type.
A
Okay,
so
if
something
like
this
is
received,
you
know
like
that
dot
turned
on,
so
a
person
is
basically
going
to,
like
you
know,
just
put
this
value
inside
of
the
field
over
here
and
then
as
soon
as
so.
Yes,
this
is
filtering
based
on
this
particular
type
and
then
based
on
the
type
that's
received.
This
is
going
to
give
users
the
ability
to
choose
what
they
want
to
do
inside
of
jenkins
and,
like
again,
as
I
said,
I
don't
know
if
this
is
the
right
way
to
go.
A
C
A
D
A
So
yeah,
so
maybe
I'll
delete
this
to
keep
the
the
ui
cleaner
and
I'll.
Also
just
have
start
here
just
but
in
your
head.
Just
think
of
this
as
a
start,
see
like
the
cloud
event
type
start
just
trying
to
keep
it
clear
here.
So
everything
kind
of
you
know
it's
cleaner
to
look
at
and
then
I
have
this
configure
additional
properties.
A
I
mean
I
did
not
know
what
better
place
to
put
this
at,
but
what
I
ideally
wanted
to
do
was
as
soon
like,
as
the
topic
received
would
be
build
job,
something
like
an
optional
block
of
selecting
an
existing
project
would
come
up
so
building
a
job
or
stopping
build
of
a
job
fire
excel
existing
project.
So
I
did
try
running
a
validation
on
on
this
particular
like
drop
down
and
then
also
on.
So
this
is
a
boolean
field,
so
I
did
try
running
a
validation,
but
that
did
not
work.
A
A
That's
something
that
we
can
figure
out
moving
forward,
but
for
now,
if
a
person
is
you
know
and
all
the
logic
of
what
happens
when
a
person
basically
does
not
choose
job,
that's
just
that
that
won't
really
affect
the
the
whole
like
experience
for
the
user
itself,
so,
okay
building
building
a
job
and
I'm
going
to
select
an
existing
project
already
kind
of
selected.
So
I'm
going
to
delete
this
wait.
Where
did
I
go?
C
A
I
have
two
jobs
right
now.
I
have
a
test
job
and
I
have
failed
job,
so
this
is
basically
giving
the
user
to
enter
the
job.
They
want.
I'm
just
going
to
select
two
jobs,
even
though
it's
meant
to
fail,
but
every
time
a
c
type
of
start
will
be
received
at
at
the
then
point
that
I
have
given
for
this
particular
like
this
plug-in
for
the
sync
every
time
this
particular
c
type
will
be
received
here
in
the
header.
A
It's
going
to
build
a
job
and
it's
going
to
build
the
test
job
and
the
fail
job
I
can
also
configure.
I
also
thought:
maybe
users
won't
want
to
do
more
of
you
know,
triggering
more
action,
so
maybe
they
want
to
have
scout,
build
up
a
job,
but
they
want
to
have
a
different
type
here.
So
maybe
this
is
original
pipeline.
A
A
A
So
if
I'm,
okay-
I'm
going
to
you-
know
it's
a
lot
of
like
repeatables
and
like
I
had
to
put
some
of
this
into
describable
into
two
different
describables
one
for
this,
this
whole
block
and
one
for
this
block
right
here
and
then
again
like
if
someone
has
to
do
another
one
of
this
whole
event,
block
of
you
know,
selecting
a
type
and
then
selecting
an
action.
It's
it
can
be.
Really
long
can
be
a
little.
A
A
C
Logically,
logically,
I
would
say
that
they
are
separated
right
because
you
can
configure
one
without
the
other,
so
maybe
even
kind
of
like
having
two
separate
screens,
at
least
for
me.
It
will
make
sense,
and
on
the
sync
side,
I
wonder
why
did
you
choose
to
put
like
the
event
topic,
which
is
the
action
that
you're
going
to
trigger
at
the
beginning?
C
D
C
Then
trigger
this
thing
against
this
kind
of
like
this
job
in
particular
right.
So
I
would
definitely
put
closer
like
the
event
topic,
the
action
and
the
selected
project
just
to
make
sure
that
they
are
close,
because
that's
kind
of
how
I
think
that
people
will
just
go
and
configure
these
things.
It's
just
kind
of
like
a
mental
flow
that
they
will
follow.
C
No,
no,
I
think
that's
that's
that's
just
kind
of
like
a
minor
detail
on
how
things
are
arranged,
and
the
next
thing
that
you
will
need
to
think
about
is
a
way
to
define.
For
example,
if
you
want
to
trigger
a
job,
you
can
trigger
it
by
name
right.
So,
for
example,
there
you
are
just
saying
just
run
the
test
and
the
failed
job.
That's
fine,
but
when
you
want
to
cancel
a
job,
you
will
probably
need
to
do
it
by
id,
not
by
name
right.
Is
that
correct.
C
A
Yes,
I
think
that
makes
a
lot
of
sense,
but,
like
I'm
thinking
is
like,
is
there
a
way
that
we
can?
You
know
like,
because
I
think,
if,
if
we
we'd
have
to
give
a
number
wouldn't
like
a
user,
would
have
to
look
it
up
first
and
then
so
what
the?
What
like
the
stop
build
of
a
job
does
right.
Now
is
basically
so,
if
there's
you
know
the.
If
I
have
this
test
or
fail,
and
if
it's
in
the
queue
any
you
know
any
job.
A
If
this,
if
a
test
is
in
the
queue
or
if
the
fail
is
in
the
queue,
it's
just
going
to
cancel
the
the
last
instance
of
what's
in
the
queue-
and
I
think
that's
really
troubling
but
like
if
we
are
giving
users
the
okay,
you
go
and
enter
the
the
field
for
the
maybe
like
the
id
or
something
I'm
just
thinking.
How
maybe
difficult
would
it
be
for
a
user
to
figure
out?
What
exactly
do
I
want
to
cancel?
D
A
I
I
think,
like
that's
something
that
I
need
to
look
into,
but
I
like
again
with
like
stopping
the
build
of
the
job
that
was.
That
was
one
thing
because,
for
example,
if
a
person
has
they
already
have
a
build
running,
for
example,
they
have
a
failed
job
running
and
if
they
have
five
of
failed
jobs
in
the
queue
and
there's
this
certain
one
with
that
was
maybe
triggered
from
like
that
was
triggered
automatically
from
like
some
external
system.
A
Let's
say
that
that
was
that's
the
the
cue
number
three
out
of
the
five
jobs
which
are
in
the
queue,
and
this
is
fail,
job
which
I'm
talking
of,
and
this
particular
failed
job
number
three
maybe
has
some
additional.
You
know,
like
particular,
let's
say
scripts
or
maybe
particular
diff
other
changes,
so
I'm
just
thinking.
Maybe
we
can
like
one
way
can
be
to
have
this
information
passed
down
from
from
the
event
body
itself.
A
So,
like
the
event
body
is
like
okay,
this
particular
job
was
rest,
like
maybe
like
tech
tone,
so
this
particular
pipeline
was
started.
This
particular
pipeline
is
using
this
this.
This,
like
maybe
like
four
different
scripts
and
each
script,
is
basically
like
each
script.
Maybe
has
an
id
right.
So
whenever
we're
passing
that
and
we're
like
okay,
we
want
this
particular
script
with
id
number
three
is
present
in
fail.
Job
number
three,
I
don't
know
if
I
I
don't
know
how
feasible.
A
That
is,
because
you
know
that's
again.
First,
it's
kind
of
like
tidally
coupling
things
and
the
second
is
it's
not
always
guaranteed
that
we
will
receive
the
event
data.
That
necessarily
is
going
to
link
the
particular
job,
that's
in
the
queue
that
we
want
to
cancel
with
with
just
like
job.
So
for
someone
says
because,
as
I
said
right
now,
this
just
cancels
the
last
job
in
the
queue,
so
there
are
five
in
the
queue
this
is
going
to
cancel
the
fifth
one
in
the
queue
and
the
other
ones
are
going
too
wrong.
C
Yeah,
it
really
depends
on
the
use
case,
but
for
some
integration
purposes
you
might
have
it
you
might
be
able
to
get
that
id
from
their
body
right.
I
mean
I
guess
that
should
be
kind
of
like
the
approach.
If
you
get
the
id
in
the
body,
you
should
try
to
parse
and
get
it
and
try
to
just
stop
that
job.
C
If
not,
you
will
just
execute
that
default
behavior
of
stopping
the
the
latest
one
or
something
like
that,
because
if
not
it's
going
to
be
very
tricky
to
figure
out
which
one
to
stop,
and
you
always
feel
will
ended
up
like
stopping
the
latest,
which
might
be
started
by
some
other
action
right.
It
might
be
just
started
manually
by
someone
else
or
by
another
event
or
or
whatever
it's
happening
in
the
in
the
in
the
ecosystem.
C
A
I
I
put
it
here
to
start
because
I
thought,
when
you
know
there
are
multiple
c
like
cloud
event,
types
that
someone
has
added
here
and
when
topic
was
at
the
bottom
of
all
of
this
it
sort
of
looked
confusing,
but
it
definitely
makes
the
most
sense
when
a
person
first
can
figure.
If
I
want
to
re,
if
I
receive
type
of
this
type,
this
type
and
this
type,
I
want
to
trigger
this
action
so,
rather
than
want
to
trigger
this
action
and
junk
into
piracy
so
and
so
types.
C
I
think
so
yeah
I
would,
I
would
definitely
add
the
filter
first,
not
100
sure
of
having
multiple
event
types
that
will
make
it
more
difficult
for
you
to
parse
right
like.
If
you
need
to
pass
the
body,
you
will
need
to
check
the
type
first
and
then
decide
how
to
parse
it,
because
different
kind,
like
events,
might
come
with
different
bodies
right
so
but
yeah.
C
A
B
D
It
makes
sense
to
explore
the
c
so
adding
like
filtering
of
like
different
headers
itself.
I
mean,
though
okay,
I'm
just
gonna
call
the
main
parts.
The
headers,
but
maybe
makes
sense
to
you,
know
figure
out
adding
if
the
adding
other
headers
will
also
help,
because
I
feel
it
would
definitely
give
more
flexibility,
because
the
type
can
be
the
same
aft
from
time
to
time.
D
D
C
D
C
C
A
D
A
D
A
A
D
D
So
sorry
in
the
cloud
event
that
is
coming
in
so
here,
as
you
said,
like
add
c
type
or
maybe
it
could
be,
something
like
you
know,
add,
add,
filter
so
and
then
in
the
filter
you
can
give
like
which
key.
And
what
value
are
you
looking
for
in
that
key?
So
that
is.
That
is
a
more
flexible
way
of
doing
things
I
feel
and
in
and
when
you're
giving
the
value
you
can.
D
A
A
D
D
A
A
I'm
just
thinking
of
how
like
how
can
we
give
user
or
like
how
can
that
be
sort
of
automated
inside
of
you?
But,
but
I
think
like
what
you
guys
have
said.
Those
are
very
good
points
and
I'm
going
to
iterate
on
making
those
and
like
changing
to
you
know
just
having
or
giving
users
the
ability
to
decide
what
can
be
the
filter
here.
D
So
it
allows
us
to
like
match
expressions,
different
kind
of
expressions
and
you
know
do
a
lot
of
different
things
with
the
incoming
data,
so
just
match
the
key
and
the
whatever
operator
you
want
to
use
and
then
the
values
so
kind
of
doing
things
like
that,
and
but
so
you
could
probably
check
that
out.
Let
me
put
that
here.
A
A
A
A
A
No,
I
was
just
saying
like
so
so
if
a
person
selected,
for
example,
if
they
selected,
stop
build
of
a
job
right
and
the
field
which
is
event
topic
inside
of
like
our
jelly
files
and
inside
of
our
java
class,
if
this
particular
like
event
topic
is
top
build
of
a
job,
then
trigger
wait.
Just
let
me
delete
this
then
automatically
like
trigger
this
particular
field.
So
as
soon
as
a
person
selected
stop
building
the
job,
because
this
is
already
like.
A
If
the
person
is
wanting
to
stop
build
of
a
job,
it
must
be
an
existing
job
so
automatically
trigger
this
field
like
like
pop
up
or
maybe
like
automatically
pop
up
or
figure
by
itself.
So
it
only
really
happens
when
I
save
it.
So
if
I
have
any
logic
like
if
the
event
topic
is
just
a
build
of
a
job,
then
select
existing
project
should
be
true,
and
all
of
that
really
happens
when
it's
being
saved
and
which
makes
sense.
A
Obviously,
but
I'm
just
thinking
when
we
are
adding
more
of
ui
how
to
prevent-
or
you
know
how
to
prevent,
putting
a
lot
of
information.
The
users
would
not
have
to
enter
for
like
select
existing
project
or
configure
new
project.
They,
if
not
need
be
here,
but
they
are
only
because
there's
no
other
way
that
I
could
figure
out
how
to
how
to
put
this
select
existing
project.
A
So
maybe
a
person
wants
to
build
a
job,
but
they
do
not
look
at
select
existing
field
at
all
and
they
do
not
understand
what
to
do
where
to
go.
So,
I'm
just
thinking
of
automating
each
step,
and
I
looked
into
like
scripts
inside
of
jelly.
I
looked
into
other.
You
know,
like
obviously
the
the
condition
programming
inside
of
jelly,
but
that
everything
works
when
it's
saved,
so
I
went
with
the
optional
blog
because
then
the
users
would
not
see
this
whole
like
text
field
when
they
do
not
have
to
enter
it.
A
A
D
It
is
possible
that
if
people
doing
a
lot
of
cloud
event,
filtering
kind
of
stuff
to
you
know
trigger
their
jobs,
there
might
come
a
point
where
it
would
like.
90
percent
of
this
would
become
90
of
global
plug-in
configuration
would
become
just
cloud
events,
so
I
think
it
makes
sense
to
invest
some
time
in
you
know
figuring
the
ui
for
that
and
I'm
also
thinking
would
it
be.
Would
it
make
sense
for
now
to
kind
of
so
now
that
we
have
an
idea
like
what
you
know
the
internals
look
like
that?
D
Okay,
we
get
a
cloud
event.
We
you
know
parse
it,
and
then
we
kind
of
on
based
on
that.
If
the
parts
passing
stuff
comes
correctly,
then,
after
that
we
we
use
some
of
it
as
parameters
and
the
rest
of
it
as
like.
You
know
which
job
probably
could
get
triggered
like
we
could.
We
can
use
this
stuff
and
then
put
into
jenkins
job
trigger
the
jenkins
job,
and
you
know
that
will
be
like
our
life
cycle
right,
but
I
think
it's
at
this
point
in
our
project.
D
D
E
A
Yeah,
that
makes
sense
and
like
the
conflict
like
configuring,
just
getting
information
from
the
ui
thing
like
that
takes
more
time
than
just
configuring,
the
plugin
and
then,
when
we
say
the
config
part
and
put
it
in
or
like
it
sort
of
abstracting
away
this
whole.
You
know
how?
How
do
we
get
this
information
like?
What
exactly?
A
D
D
So
it's
probably
like
this
week.
What
we
can
do
is
we
can
like
figure
out
like
what
that
would
look
like
and
like
just
under
cloud
events.
So
you
got
like
this
entire
big
cloud
event
thing
and
then
under
that
probably
you've
got
like
I'm
thinking,
yaml
right
now,
so
you've
got
like
the
cloud
events,
okay,
cloud
events,
colon
I
go
down
double
space,
then
I'll,
write
sinks.
D
Then
colon,
then
I'll
go
down
and
I'll
start
a
list
over
there
right
I'll
start
a
list,
I'll
put
a
dash
I'll
say,
like
name
yeah.
So
what
is
the
name
of
the
sync
and
then
something
like
that?
So
configuring
jenkins
is
a
sync.
Do
I
want
multiple
things
here
or
like
just
one
sync,
so
I
that's
what
how
I
figure
it
out
so
to
start
off.
D
A
D
Really
don't
know
what
you're
going
through
right
now
dealing
with
all
of
this
jelly,
because
I
know
it's
not
easy
to
figure
this
out
and
it's
it's
not
even
java.
It's
just
xml
of
some
sort.
Maybe
doing
this
exercise
could
also
you
know.
Take
you
out
of
this
a
lot
of
jelly
that
you
probably
have
been.
You
know
trying
to
figure
all
this
out.
I
don't
think
just
it
will
help
help.
You
clear
your
mind,
a
lot
about
these
things
and
obviously.
D
E
So
I
I
mean
I,
I
think
that
that
is
the
best
way
to
configure
it,
and
I
mean
I,
I
don't
think
m
m,
like
any
development
tools,
you
know,
there's
that
that's
you
often
configure
them
with
with
yaml
or
json
or
something
I.
I
think
that
most
plug-ins,
though,
do
have
to
have
some
ui
as
well,
but
the
other
thing
is:
if
we're
talking
about
some
sort
of
a
standalone
ui
that
that's
not
part
of
the
the
system
configuration
settings,
I
don't
think
that
has
to
be
in
jelly.
E
E
E
So
you
you
can,
yes,
you
can,
and
and
but
I
I
think
that
if
if,
if
we
have
a
standalone
ui
where,
where
it's
not,
you
know
not
part
of
an
existing
page
like
this,
it's
even
easier
you
can
you
can
you
can
do
it
on
the
system
on
the
system
configuration
page,
but
it's
it's
kind
of
hard
to
figure
out
how
to
how
how
to
plug
it
in.
But
if
it's
a
standalone
thing
that's
totally
separate,
then
I
think
that
we
can
use
anything.
We
want.
E
F
E
E
E
A
Yeah,
I
I
had
loaded
into
the
like
the
thin
backup,
plug-in
and
also
a
couple
other
plug-ins,
so
some
of
them
are
using
ruby.
Some
of
them
have
like
this
scripting
section
inside
of
jelly,
which
is
doing
you
know
a
lot
of
maybe
works
with
displaying
the
the
list
or
doing
the
work
with
what
happens
when
something
is
submitted.
A
But
again,
yes,
that
was
not
inside
of
global
config,
so
the
google
config
works
very,
I
think,
like
differently,
but
also
very
attached
with
how
jenkins
saves
and
from
like
how
jelly
saves
information
inside
of
global
configuration,
and
that's
why
scripting
here
was
not
working.
I
did
try
using
that,
but
if
yes,
maybe
the
next
option
is
to
actually
move
out
of
google
configuration
and
I
did
try
another
like
a
clone-
that
I
have
and
tried
using
like
extending
and
working
with
management
link.
A
But
I
wasn't
sure
if
this
is
working,
so
I
stuck
with
on
global
config,
but
you
guys
are
really
right
on
how
this
is
becoming
really
a
hefty
task
for
users
or
just
to
you,
know,
think
of
and
develop.
So
I
think
it's
really
the
time
to
move
away
from
google
configuration
and
think
of
other
ways
to
achieve
the
same
effect
and
reduce
this
overhead
of
just
designing.
E
A
Yeah
because
yeah
the
scripting
with
jelly-
I
I
looked
at
like
I
looked
at
a
lot
of
plugins
just
to
figure.
You
know
this
repeatables,
the
additional
properties
and
the
auto
complete,
so
it
did
find
a
good
amount
which
we're
using
like
javascript
scripts
inside
of
jelly,
and
this
is
really
cool
and
then
I
did
try
implementing
it
inside
of
global
configuration,
but
it
wasn't
working
and
at
that
time
I
had
some
things
down.
A
If
this
works,
then
I'm
going
to
move
away
and
spend
my
time
in
designing
it
in
the
simpler
terms
with
yaml
and
configures
code
is
added
to
this
plugin
and
it
does
work.
I
checked
it.
But
again
you
know
someone
might
not
look
into
that
and
someone
might
come
to
this
plugin.
So
I
don't
really
know
how
I
didn't
know
how
to
simplify
it,
but
I
do
know
now,
yes,
moving
away
from
moving
away
from
those.
E
A
Thanks
jeff,
yes,
that
that's
going
to
be
really
helpful,
and
even
if
we're
not
using,
maybe
just
like
react,
we
can
look
into
just
plain
javascript
and
if
anything
that
that
works,
and
it's
better
than
this,
I
think
that
the
readme
can
fit.
It
actually
looks
really
cool
and
complex
it
like
complex.
For
you
know,
we
can
get
a
lot
of
information,
but
not
to
actually
configure.
D
D
A
D
D
There
are,
there
are
a
few
things
that
that
would
be
nice
to
have,
which
are
quite
agnostic,
and
you
know
that
gives
us
like
something
to
work
with,
because
it's
made
by
someone
working
in
k
native,
and
we
have
a
good
idea
of
how
to
pass
this
cloudy
cloud
event
stuff.
I
think
that's
a
good
way
to
that.
That's
a
thing
that
you
could
do,
but
I
would
like
I
would.
D
It
is
like
possible
to
kind
of
get
off
track,
maybe
a
little
bit
or
like
you
know,
just
not
off
track
but,
like
you
know,
get
a
little
lost
which,
which
kind
of
which
can
be
detrimental
and
like
we.
We
start
solving
problems
that
don't
exist
or,
like
we
start
extending
things
like
which
are
like
kind
of
out
of
scope
in
a
way.
A
Yes,
yes,
those
are
very
good
suggestions
and,
honestly,
like
good
ideas
for
the
work
that
needs
to
be
done
and
also
we
have.
You
know
two
minutes
going
beyond
the
meeting
time,
but
I
really
appreciate
the
suggestions
and
all
the
health,
for
you
know
like
the
the
plug-in
and
the
ui
and
all
of
that
stuff,
and
there
was
one
more
thing,
but
I
think
we,
the
this,
is
the
more
prominent
thing
and
just
the
sync
implementation
again
when
we're
talking
about
it's
the
next
week.