►
From YouTube: 2022-01-11: Object Storage Working Group - APAC
Description
No description was provided for this meeting.
If this is YOUR meeting, an easy way to fix this is to add a description to your video, wherever mtngs.io found it (probably YouTube).
A
Okay,
so
we
are
recording
welcome
everyone
good
morning,
good
afternoon.
This
is
january,
11th,
yeah
11th,
and
this
is
the
apoc
friendly
object,
storage
working
group
meeting
the
first
one
of
the
is
it
no?
It's
not
the
first
one,
it's
the
first
one
of
new
here
for
the
apoc
friendly,
but
not
the
first
one
in
general.
So
I
would
like
to
thank
mathias
and
jason
as
well
for
running
the
meetings
where
I
was
on
pto,
and
so
let's
get
started.
A
A
We're
kind
of
on
this
point
where
we
acknowledged
the
desire
to
work
on
a
say,
more
long-term
solution
for
the
problem
itself
and
not
just
to
stop
at
the
the
the
first,
let's
say,
quick
solution
that
can
just
help
us
to
to
solve
the
some
of
the
pain
points.
So.
B
A
Yeah
yeah,
my
point
was
about
the
timeline
that
if
we
take
this
last
month
that
we
have,
maybe
we,
if
we
focus
on,
say
the
short-term
solution,
we
can
have
it
down
done
by
being
not
done
the
solution
but
define
well-defined
by
the
end
of
the
month.
But
this
is
not
the
desire
of
the
working
group
members
because
we
want
to
do
both
things
as
well.
A
B
Yeah,
I
think,
like
back
to
your
point,
are
we
still
going
to
have
at
least
one
meeting
before
you
go
on
the
parental
leave?
B
So
perhaps
you
know
we
will
be
able
to
find
a
volunteer
by
then
I
I
can
also
talk
to
my
manager
to
see
if
you
know
there
is
what
the
expectations
are
around
my
future
capacity,
and
perhaps
you
know
I
can
I
can
help
here,
but
if
there
is
someone
who
would
like
to
take
it
over
from
malaysia
for
the
next
two
months
that
yeah,
let's,
let's
encourage
everyone
to
double
check
with
their
managers,
and
perhaps
we
can
talk
about
that
in
the
next
week.
B
Okay,
so
let's
move
to
the
to
my
next
point
so
some
time
ago
I
created
this
google
spreadsheet
about
possible
solutions
and
scoring
we
kind
of
we're
not
able
to
actually
describe
some
solutions
possible,
long-term
solutions.
So
we
have
not
scored
them
yet
because
we
we
don't
know
what
they
might
be.
So
the
question
is
whether
we
actually
want
to
document
possible
long-term
solutions,
and
how
do
we
want
to
approach
that
topic
yeah
to
choose
the
solution
that
we'll
describe
in
the
blueprint.
A
Okay-
so
I
was
thinking
about
this
last
year
sounds
weird,
but
yeah
it
was
last
year,
so
I
I
do
agree
that
that
effort
requires
a
better
definition
of
the
of
the
solutions
themselves.
A
So
this
is
something
I
mean
it's
really
hard
to
score,
something
if
there's
no
a
concrete
plan
for
it.
On
the
other
hand,
I
think
that
the
from
0
to
10
is
really
a
wide
spectrum
of
values.
It's
really
different.
I
mean
how
can
you
find
the
difference
between
a
six
level
solution
compared
to
a
five
or
four
so
shrinking
something
in
the
realm
of
zero
to
five
or
even
less,
maybe
kind
of
because
it's
easier
to
think
about?
I
think
that
I've
wrote
something
in
the
chat.
A
Let
me
find
quickly
find
this
something
like
it.
It
makes
things
worse,
something
like
maybe
three
is
the
middle
line
would
say
neither
worse
nor
better
than
the
current
status,
and
then
you
kind
of
have
two
above
and
two
below
something
like
introducing
technical
depth
or
make
things
considerably
worse.
So
this
is.
This
is
going
to
be
two
and
one
and
on
the
other
hand,
you
had
improve
something
and
just
kind
of
a
desired
solution:
long-term
desired
solution
for
the
specific
criteria,
so
it's
kind
of
easier
to
to
compare
them.
B
A
B
Important
is,
to
kind
of
you
know,
focus
on
scoring
the
potential
a
given
solution
has
instead
of
concrete
details,
because
they
do
not
exist
yet
and
that's
the
whole
point
of
the
architectural
evolution
and
our
architecture,
evolution
and
blueprints.
We
are
writing
it's.
You
know
a
vision
and
we
want
to
kind
of
score
the
vision,
not
a
concrete
solution,
because
the
concrete
solution
will
be
only
known
after
it's
implemented.
B
Even
one
day
before
the
you
know,
someone
wants
to
merge.
Something
like
there
can
be
a
significant
changes
in
the
code
and
basically
you
know
it's.
You
never
know
what
you
will
end
up
with
until
you
actually
build
that
and
that's
the
whole
point
of
the
iteration
to
learn
from
previous
step
between
you
know
incorporate
feedback
into
the
next
one
so
yeah.
For
me,
it's
like
not
a
huge
difference
between
zero,
ten
and
one
five,
but
if
one
five
is
or
one
six
is
easier
or
zero,
six
or
zero.
B
Five,
like
that's,
that's
fine,
I
I
think
what
we
are
missing
here
is
a
couple
of
visions
of
the
future.
D
And
can
I
sorry
to
interject,
but
I
think
before
we
get
carried
away
in
the
mind,
we
share
the
exact
rubric
that
we're
gonna
to
use
my
problem
with
this
as
it
stands,
and
I'm
not
sure
others
feel
about
this.
I
couldn't
even
begin
to
score
this
because
I
haven't
worked
with
object,
storage
pretty
much
at
all,
and
if
I
go
to
these
points
I
mean
with
the
comments
added.
D
I
have
a
vague
idea
of
what
it
means,
but
I
I
couldn't
know
like
what
the
impact
would
be
or
how
complex
it
would
be
to
implement
if
that.
If
that
is
the
question,
so
so
I
don't
even
know
like.
Are
we
suggesting
that
every
that
we
all
score
this
everyone
on
the
group,
because
I
I
just
have
no
idea
what
most
of
this
even
means?
I
think
this
is.
D
Of
feedback
and
another
one
I
would
have,
I
think
I
mentioned
it
last
time
gregor
when
when
it
was
just
the
two
of
us,
no
one
else
was
there.
What
I
miss
in
this
picture
is
a
sense
of
linearity,
like
that.
This
is
like
like
more
than
20.
This
is
like
25
items.
I
have
no
idea
how
they
relate
to
each
other.
Like
is
this
something
that
we
would
all
have
to
do,
or
is
there
like
a
subset
of
things
that
we
could
do
you
know
to
like
move
this
project
ahead?
D
I
I
think
what
I
would
maybe
like
at
the
next
exercise.
Before
we
start
scoring,
we
should
identify.
I
could
imagine,
maybe
I'm
wrong,
like
you
correct
me,
but
like
if
I
could
imagine
there
are
some
items
to
a
three
that
absolutely
must
happen
for
other
items
on
this,
this
to
even
be
feasible
right.
D
So
so
I
can't
imagine
that
all
of
these
are
entirely
self-contained,
so
I'm
just
wondering
would
it
make
sense
to
have
more
of
like
a
a
tree
based
approach
first,
which
says
like
for
I'm
just
like
this
might
be
wrong,
I'm
just
for
the
sake
of
example.
Maybe
we
need
to
look
at
replacing
carry
away
first
before
we
look
at
items,
you
know
x,
y
and
z,
right
and
that
to
me
would
already
kind
of
update
any
sort
of
scoring
anyway,
because
it
means
we
just
have
to
do
it
right.
D
It's
like
a
reasonable
next
step
to
do.
Then
we
can
kind
of
linearize
this
right.
We
can
then
say:
okay
well.
If
it
enables
x,
y
and
z,
we
can
score
those
and
then
kind
of
order
them
by
by
score.
So
so
for
me,
like
there's,
just
not
enough
structure
right
now
to
even
make
any
sensible
decision
of
what
to
pick
up.
B
So
so
that's
a
great
feedback
and
I'm
thinking
about
how
can
we
actually
improve
that
google
doc
to
make
it
easier
to
score
these
things?
I
wonder
if
perhaps
the
boring
solution
here
would
be
to
divide
the
scoring
items
into
three
groups,
things
that
need
to
happen,
things
that,
like
most
likely,
should
happen
and
things
that,
like
are
kind
of
you,
know
nice
to
haves,
and
perhaps
you
know
we
could
assign
a
different
way
to
scores
in
the
most
important
things
group
and
like
perhaps
this
would
helpful
mathias.
D
A
C
Yeah
when
we
were
doing
pages
three
architecture,
we
just
had
two
competing
proposals:
one
from
camille
and
one
from
jakob.
We
implemented
very
different
ideas
and
it
was
much
much
easier
to
compare
things
and
even
I
don't
know
understand
them.
When
you
can
just
look
at
the
code,
you
can
run
it
even
if
it's
not
fully
functional,
it's
not
able
to
migrate
anything
so
yeah.
What
do
you
think
if
we
just
document
some
of
the
ideas,
maybe
find
people
who
can
be
responsible?
C
If
someone
is
super
passionate
about
some
concrete
ideas,
then
they
can
take
some
time
to
implement
a
very
quick
and
duty
poc
and
then
you
can
just
come.
Compare
them
and
it
will
make
the
discussion
much
more
focused
and
we
won't
just
discuss
some
random
numbers.
We
will
actually
see
how
it
can
work.
C
A
Yeah
I
want
to
double
down
on
this
reporting,
something
that
camille
told
me
about
the
sharding
effort,
so
I
will
share
the
his
feedback
on
how
they
did
the
things,
so
they
had
competing
solution
like
in
the
pages
situation,
and
some
of
them
were
looking
good
on
paper
and
someone
that
had
some
kind
of
there
were
some
kind
of
trade-offs
right,
but
then,
when
they
started
doing
the
poc,
the
one
looking
good
on
papers
were
kind
of
a
nightmare
to
implement,
so
they
were
just
kind
of
touching
everything
it
was
really
hard
to
to
develop
or
to
maintain.
A
So,
even
though
on
paper,
something
looks
better
than
they
say.
No,
this
is
kind
of
takes
years
to
complete
and
there's
no
say
no
iterative
tangible
benefits
in
between
it's
kind
of
a
a
flag
day
situation.
Where
is
not
working
until
it's
working
and
you
get
the
that
point
where
things
are
working
two
years
down
the
pipeline
wrestlers.
This
can.
This
is
gonna,
never
happen,
but
this
was
not
clear
by
looking
at
how
the
architecture
should
work.
So
I
I
would
say
that
yeah,
if
we
have
some
kind
of,
I
will
use
my
example.
A
The
carry
wave
replacement
as
a
as
an
example,
so
that
one
is
absolutely
not
complete
but
shows
you
some
kind
of
a
flow.
So
how
does
it
work
when
something
comes
into
the
product
and
how
things
are?
What
are
the
actors,
the
components
in
this
type
of
interaction
and
how
they
are
supposed
to
behave
right?
So
I
think
that
that
one
is
is
well
defined
to
the
point
that
someone
can
actually
start
working
on
a
poc
and
coming
back
with
questions,
so
it
this
can't
work
or
how
do
we
think
this
situation
should
be
handled?
A
D
I
was
also
wondering:
are
there
any
items
already
on
this
list
so
that
we
can
think
of
that?
We
would
kind
of
want
to
do
anyway,
like
regardless
of
the
ultimate
approach
that
we
take.
Let's
just
assume,
we
have
two
kind
of
competing
visions
that
would
at
some
point
go
in
a
different
direction,
but
I'm
wondering
because
I
remember
also
going
back
to
what
are
we
kind
of
trying
to
solve,
for
there
was
some.
D
There
was
a
lot
of
a
lot
of
points
around
like
the
developer
ergonomics
and
it's
like
really
hard
right
now
to
implement
a
new
kind
of
upload,
some
technical
debt
as
well-
and
I
saw
there's
some
points
around
libraries
that
we
use
like
fog-
I
mean:
are
they
like
general
cleanup
tests
where
we
can
say
these
are
just
no-brainers?
We
should
just
do
them
like
regardless
of
this
or
that
architectural
approach.
I
mean
because,
like
approaching
it,
this
way
as
well
might
just
get
some
of
that
yeah.
D
A
Things
tends
to
be
really
badly
coupled
in
the
way
things
are
implemented
right
now,
which
is
why
one
of
the
thing
was
about
if
we
have
a
short-term
solution
type
of
goal
and
so
that
we
have
so
it's
kind
of
a
clean
up,
you're
suggesting.
But
the
point
is
that
I
can't
find
a
low-hanging
fruits
on
this
situation,
and
so
they
are
kind
of.
We
need
a
bit
of
a
more
organic
solution
to
get
to
a
point
where
we
can
evolve
it
into
something
completely
new
future
proof
or
things
like
that.
A
But
I
mean
this
is
my
view
on
on
my
experience
and
exposure
on
this,
because
it's
they
are
all
badly
capped
in
terms
of
we
don't
have
a
generic
object
storage
place.
So
you
can't
direct
upload
everything
that
is
coming
through,
as
well
as
because
it's
not
implemented
in
workers,
but
there's
not
even
a
place
to
put
all
those
information,
and
then
you
have
the
carrier
wave,
which
is
the
default
implementation
that
we
have
so
on
rail
side.
A
If
you're
gonna
add
more
say
you
default
everything,
so
you
decide
to
work
on
defaulting
everything
to
object,
storage,
direct
upload.
Then
you
are
kind
of
making
bigger
the
time
the
amount
of
things
that
you
have
to
migrate
off
carrier
wave
because
skyway
they
are
the
first
thing
you
have.
So
that's
that's
the
type
of
situation,
but
probably
looking
closely.
We
can
try
to
identify
something
that
is
kind
of
a
natural
first
step,
but
yeah,
I'm
afraid
this
is
kind
of
more
than
one
single
step.
A
Okay,
so
if
there
are
no
other
items,
we
are
almost
at
time,
but
I
think
it
was
a
great
conversation
today,
so
I
will
try
to
wrap
things
up
and
just
yeah
to
and
so
that
we
can
think
about
this.
We
can
think
about
who
can
continue
this
work.
In
my
absence
I
had
before
before
the
break,
I
had
a
conversation
with
son
who,
as
well
who's
kind
of
asking,
if
he's
willing
to
mentor
whoever
decide
to
con,
continue
working
on
this
because
he's
a
lot.
A
He
had
obviously
had
a
lot
of
experience
on
this
topic
as
well,
so
he
agreed
that
he
can
help
and
mentor
who
wants
to
continue
on
this
effort.
So
if
someone
wants
to
volunteer,
you
would
not
be
alone,
okay,
so
that
that's
an
important
message
that
I
wanted
to
pass
on.
So
thank
you
everyone.
I
will
leave
you
to
the
rest
of
your
days
or
evening
and
see
you
soon.